Sparkle.LinkedInNET will help you query the LinkedIn API :)

Bring the .NET world a nice LinkedIn client library.

LinkedIn recently changed a lot of things in its developer program. When using this API, your applications might break on May 12, 2015.

Many documented URLs in this project are broken because LinkedIn changed the documentation pages. Here is the old documentation via the WaybackMachine.

Starting on May 12, 2015, we will be limiting the open APIs to only support the following uses:

• Allowing members to represent their professional identity via their LinkedIn profile using our Profile API.

• Enabling members to post certifications directly to their LinkedIn profile with our Add to Profile tools.
• Enabling members to share professional content to their LinkedIn network from across the Web leveraging our Share API.
• Enabling companies to share professional content to LinkedIn with our Company API.

All other APIs will require developers to become a member of one of our partnership programs.

For many developers, we understand that today’s changes may be disappointing and disruptive, but we believe these changes will provide further clarity and focus on which types of integrations will be supported by LinkedIn.

-- Changes to our Developer Program, February 12, 2015

See also Transition FAQ, D-Day's changes.

By using the LinkedIn APIs you agree to the LinkedIn APIs Terms of Use.
This project is released under the LGPL v3 license.
This is NOT an official client library.

Via NuGet

PM> Install-Package Sparkle.LinkedInNET

Or build the sources... You have to create your own .snk file.

The LinkedInApi class is the entry point for all API calls. You must instantiate it with a configuration object. The minimum configuration is the API key and secret. Get a LinkedIn API key.

// create from config file
var config = LinkedInApiConfiguration.FromAppSettings("MyDemo.LinkedInConnect");
// or manually
var config = LinkedInApiConfiguration("api key", "api secret key");

// get the APIs client
var api = new LinkedInApi(config);

<configuration>
  <appSettings>
    <add key="MyDemo.LinkedInConnect.ApiKey" value="•••••••" />
    <add key="MyDemo.LinkedInConnect.ApiSecretKey" value="•••••••••••••" />
  </appSettings>
</configuration>

The OAuth2 authentication process is fully supported. The GetAuthorizationUrl method will generate the OAuth2 url to navigate the user to.

var scope = AuthorizationScope.ReadBasicProfile | AuthorizationScope.ReadEmailAddress;
var state = Guid.NewGuid().ToString();
var redirectUrl = "http://mywebsite/LinkedIn/OAuth2";
var url = api.OAuth2.GetAuthorizationUrl(scope, state, redirectUrl);
// https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=...

When the user is redirected back to your website, you can get an access code.

// http://mywebsite/LinkedIn/OAuth2?code=...&state=...
var userToken = api.OAuth2.GetAccessToken(code, redirectUrl);

var user = new UserAuthorization(userToken.AccessToken);
var profile = api.Profiles.GetMyProfile(user);

Yes, you have to pass the token for each call. This might seem redundant for some but we prefer stateless objects for multi-threaded contexts.

The API uses field lists to fetch the desired data. Simple extension methods will allow you to make strongly-typed field selection.

var profile = api.Profiles.GetMyProfile(
    user,
    FieldSelector.For<Person>().WithFirstname().WithLastname().WithLocationName());
// https://api.linkedin.com/v1/people/~:(first-name,last-name,location:(name))

The .WithAllFields() method will generate the list of all available fields. It is not recommended to do that.

var profile = api.Profiles.GetMyProfile(
    user,
    FieldSelector.For<Person>().WithAllFields());
// https://api.linkedin.com/v1/people/~:(all available fields here)
// however it is not recommended to specify all fields

You can create your own extension methods when you desire many fields. Check the source code to see how it works.

API error results throw LinkedInApiExceptions. You can find extra info in the Data collection.

try
{
    var profile = this.api.Profiles.GetMyProfile(user);
}
catch (LinkedInApiException ex) // one exception type to handle
{
    // ex.Message
    // ex.InnerException // WebException
    // ex.Data["ResponseStream"]
    // ex.Data["HttpStatusCode"]
    // ex.Data["Method"]
    // ex.Data["UrlPath"]
    // ex.Data["ResponseText"]
}
////catch (Exception ex) { } //  bad, don't do that

Library internal errors throw LinkedInNetExceptions. You should not catch them as they do not represent a normal behavior. This may be usefull when waiting for a fix.

You should not catch WebExceptions as they are wrapped into LinkedInApiExceptions.

Code documentation is quite present. Use the auto-completion to discover stuff.

The MVC demo app has a /Explore page that demonstrates most API calls. Have a look at it.

We are generating code based on a XML file. This XML file is manually filled to represent the API. We worked hard to bring something reliable. The API coverage should be implemented by expanding the XML file and enhancing code generation.

To generate the API code, build the "ServiceDefinition" project in Debug mode, then "Run custom tool" on the Service.tt file. The XML file will be read and most of the code will be updated automagically.

To alter code generation, search for CSharpGenerator.cs. Different methods are responsible of generating different parts of C# code (return types, api groups, selectors).

To add/alter API methods and return types, search for LinkedInApi.xml. This file describes the API in a human-readable and machine-readable way. Don't forget to re-generate the code (Service.tt).

https://developer.linkedin.com/apis
https://developer.linkedin.com/documents/authentication

Supported .NET Framework versions:

• .NET 4.0 (dependencies: Newtonsoft.Json ≥ 4.5.8)
• .NET 3.5 (dependencies: Newtonsoft.Json ≥ 4.5.8)

We are using a lot of code generation so it won't be difficult to target 4.5 or any other framework. Implementing the async pattern won't be hard either.

Because of the API policy changes, most API calls are now reserved to the partners LinkedIn chose. We will try to keep up using our basic API key.

See our internal to-do list.