When I requested the /rest/me LinkedIn API endpoint...
curl --location 'https://api.linkedin.com/rest/me' /
--header 'Content-Type: application/json' /
--header 'Authorization: Bearer {MY_TOKEN}' /
--header 'LinkedIn-Version: 202306'
--header 'X-Restli-Protocol-Version: 2.0.0'
I got an error...
{
"status": 403,
"serviceErrorCode": 100,
"code": "ACCESS_DENIED",
"message": "Not enough permissions to access: partnerApiMe.GET.20230601"
}
My access token had the permission scope listed in the API docs (r_liteprofile). So, I sent a message to the LinkedIn Developer Support team, and they said...
... support for r_liteprofile was dropped from version 202306 onward, but we are trying to get official confirmation of that decision to get documentation updated. The minimal permissions allowed for /me access would now be r_basicprofile going forward.
Got it. API docs were wrong. So, I changed the permission from r_liteprofile to r_basicprofile, generated a fresh access token, but I still got the same error.
A few hours later, I test the code again, and it worked! But why?
After you change permissions, wait at least 5 minutes before testing.
There is a caching bug with LinkedIn API access tokens.
Generating a new access token SHOUD invalidate the previous token, but there is a 5 minute window when your new token might behave like an old token (using old permissions / scopes).
This makes LinkeIn API development very difficult. Any time a developer makes a change to the permission scopes, new tokens may throw (invalid) permission errors for several minutes, making it seem like the scope change didn't make any difference. Then a few minutes later, the new permissions will unexpectedly kick in, making it hard to reproduce the bug.
I reported this to the LinkedIn Developer Support team with an app to prove it, and they responded...
After much discussion, team has confirmed they will consider this as part of product improvement but for now 5mins TTL is expected behavior. Developers usually don't have this pattern of trying to generate token for different combination of permissions. This is more like rare use case.
For now we have added this feedback to our roadmap. Unfortunately, we don't have concrete timeline as to when this will be implemented into production
I disagree. Changing permissions and generating new tokens is something that developers will do often, as they try to figure out what permissions are required for different API calls. I know I did it many times, especially after finding out that some of the API docs weren't being kept up to date... just had to keep remembering to wait 5 minutes before testing.
If you run into this issue please report the bug to LinkedIn, so they will see how many developers are bumping into this problem.
This also creates a problem when upgrading the LinkedIn-Version. In version 202306, they changed the permission required on the /rest/me endpoint -- from r_liteprofile to r_basicprofile. This means that we will have to ask some customers to reauthorize their LinkedIn account, to get a new access token (with r_basicprofile scope). But they might run into this caching bug, and get permission errors, if their old token (with r_liteprofile) was used in the past 5 minutes.