Transition FAQ

April 9, 2015

On February 12th, we announced some significant changes to our Developer Program.  As developers prepare their applications for the May 12th, 2015 transition date, we would like to take a moment to share some of the most commonly asked questions and provide clarity in order to make the transition as smooth as possible for everyone.

Remember, if you are an existing LinkedIn partner, or have otherwise been in discussion with LinkedIn regarding continued access for your application, the changes on May 12th may not affect you.  If you have any questions, please reach out directly to your LinkedIn Business Development representative.

Is there a sandbox available where I can test my application against the new restrictions?

No, we do not have a sandbox environment available to test against.  Read on for more information about how you can test your application’s compatibility post-May 12th.

OK, so how do I ensure my app won’t break on May 12th?

All of LinkedIn’s API endpoints are organized under specific member permissions that grant the ability for your application to call them.  The upcoming changes will not affect how any of the APIs work (with one exception noted in point #2 below), only whether you will be able to call them any longer.

As a result, testing your application for compliance can be done in one or two easy steps, depending on the types of calls that it needs to make:

  1. Create a test version of your application (or modify an existing dev/staging copy) and restrict the authorization process to request only any of the following member permissions that it requires:

    r_basicprofile
    r_emailaddress
    w_share

    If you have applied for the Apply with LinkedIn use case and have been granted permission, you may also request:

    r_fullprofile
    r_contactinfo

    Lastly, if your application uses the following member permission, ensure you read point #2 below before you can safely request it from your test application:

    rw_company_admin

    Next, run your own app’s tests to ensure it is still functioning normally.  As long as your application works using the member permissions listed above, it will continue to function normally after May 12th.

    If it fails, you will need to remove any of the failing API calls that your application will no longer have the permission to make.

  2. Finally, if you are making any calls to the /v1/companies endpoints, requiring the rw_company_admin member permission, ensure that the user(s) of your application making those calls are listed as official administrators of the companies the calls are being made against.

    If your application is not already doing so, this can be checked programmatically with the Is Company Admin API call.

Will existing access tokens expire?

Any access tokens granted prior to May 12th will live out their normal 60-day lifespan with the privileges that they currently hold today.

Beginning on May 12th, you should not expect any new or refreshed access tokens that your application requests to be issued for any of the member permissions not explicitely mentioned above.  Authentication requests will fail if your scope continues to request member permissions that you are no longer available to the public!

Are the hourly and daily call quotas changing?

Nope!  You will still be able to make the same amount of calls you always could.

Is the process for authorizing users changing at all?

Nope!  The OAuth 2.0 workflow remains the same.

Similarly, the OAuth 1.0a workflow remains unchanged, however we are no longer encouraging its use over OAuth 2.0.  Therefore, the documentation and tools for working with OAuth 1.0a have been removed from the Developer website.  We have no plans to actually deprecate this capability, so existing implementations will continue to work until further notice.

I’m using a third-party library to integrate LinkedIn with my app. Will it still work?

The answer to this question is highly situational.  In general, 3rd-party libraries should continue to function normally, however there are two important caveats:

  1. If your library handles authentication with LinkedIn, it is possible that it is hard-coded to request specific member permissions during the auth workflow, and as a result, may possibly be asking for permissions that you will no longer be allowed to ask for.  If this is the case, the authentication request will fail, and any of your users that require a new access token will be blocked at the authentication stage.

    We strongly recommend that you ensure that you know exactly what member permissions your library is requesting on your behalf and make changes to only request valid ones to avoid potential disruption.  Contact the library authors if you are unable to confirm this yourself.
  2. It’s possible that 3rd party libraries are masking one or more LinkedIn API calls behind higher-level convenience methods.  If you are not familiar with the raw REST API calls that your library is making on your behalf, please pay special attention to testing your applications.  The library’s abstraction of actual API calls from you could make it difficult for you to determine whether the calls your application is making will continue to function properly after May 12th.

All of the necessary changes required to remain functional can be implemented immediately, ahead of the May 12th transition date, so there should be no concern about coordinating the release of any code changes with LinkedIn.

Finally, if you still find you have questions about what will be possible after May 12th, please take a moment to check out our Apigee API console and browse the updated documentation on the Developer website.  Both resources accurately reflect the functionality and API calls that will remain available to the broader development community going forward.

Topics