The Live Connect APIs enable client-side and server-side websites and scripts to work with info in Outlook.com, Microsoft OneDrive, and other services that are compatible with Live Connect. An example of a client-side or server-side website or script is a web browser or a web-browser control that enables a user to interact with a website.
Note If you're working on a Windows Store app, a Windows Phone app, or a mobile app (even if those apps include website implementations), this isn't the topic you need. Go to Windows Store apps, Windows Phone apps, or Mobile and Windows desktop apps, respectively.
Before you can start calling the Live Connect APIs, you need a client ID, a client secret, and a redirect domain. For instructions, see Configuring your app.
To get you started, here's the basic code that shows how to reference the Live Connect APIs, invite a user to sign in, get the signed-in user's permission to get his or her basic profile info, and display a greeting with the signed-in user's first and last names.
<!DOCTYPE html> <html> <head> <title></title> </head> <body> <script src="//js.live.net/v5.0/wl.js"></script> </body> </html>
constants.js (replace YOUR_CLIENT_ID with your app's client ID and YOUR_REDIRECT_URL with your app's redirect URL)
To learn how to use many of the code examples throughout this documentation in the context of a larger reference code sample, see Working with the code examples.
When you are developing a web app, it is convenient to test the app on a local computer before you deploy it to a web server. However, the Live Connect APIs require the redirect URL to use the same domain at which the app's client ID was configured. Your local computer's web server probably uses a default address like http://localhost, so you must map your domain to the Internet Protocol (IP) address of your local web server. To do this, you add a mapping to the hosts file on your computer. (The job of the hosts file is to map host names to IP addresses.) On Windows computers, the hosts file is located at \Windows\System32\drivers\etc\hosts. On Mac OS X and most Unix computers, it is located at /private/etc/hosts. The format is the IP address, followed by the domain to map, like this.
127.0.0.1 MyDomain.com 127.0.0.1 AnotherDomain.com
The preceding example demonstrates mapping two arbitrary domain names to the IP address for localhost. With these mappings in place, every time you navigate to MyDomain.com or AnotherDomain.com, you will be redirected to 127.0.0.1 (http://localhost). The mappings in the hosts file apply to all web navigation, including redirect URLs that are returned by the Live Connect APIs. This works because the Live Connect APIs do not check the actual IP address that is in use, the APIs only verify the domain name. If your client ID was configured with a redirect URL of http://MyTestingDomain.com/MyApp/callback.htm, you update your hosts file with the following mapping: 127.0.0.1 MyTestingDomain.com. Now if you enter "MyTestingDomain.com" into your browser, it will resolve to http://localhost, so you can use your local web server for testing.
Elevated (or root) privileges are required to edit the hosts file, regardless of platform.
You can map an externally available domain to your local server IP address, but you must comment out the mapping when you want to view the actual website. This applies only to the computer on which the hosts file was modified. This is a handy trick because it makes it easy to switch between your externally available website and your local test website.
From here, we suggest starting with the info in Core concepts, Identity API, Outlook.com API, and OneDrive API. If you're writing code for a server-side website or script, be sure to see Server-side scenarios, too.