The integration passes every test. Two months later, every call comes back 401 — and nothing in your code changed. LinkedIn issued the token with a 60-day clock, and the mechanism most developers assume will renew it quietly is not available to most applications.
This is one of the most expensive surprises in a LinkedIn build, because it is discovered in production, by a customer, after the architecture is already frozen. It also is not a bug you can patch. LinkedIn documents the token lifetimes plainly, and it documents who is allowed to renew tokens without dragging the member back through a login screen. If your app is not in that group, the fix is an access-programme problem, not an engineering problem.
What LinkedIn actually documents about token lifetime
Two numbers govern every LinkedIn integration, and they sit on separate pages, which is part of why teams miss them.
Read those together and the shape of the problem appears. There is no long-lived token. There is a 60-day ceiling on every access token. And the only documented way to mint a new one without user interaction is a refresh token — which brings us to the sentence that decides your architecture.
The sentence that turns this into an approval problem
Refresh tokens on LinkedIn are not a feature you enable in a settings panel. They are attached to an access programme. An ordinary developer application — the kind you create in the Developer Portal in five minutes — is not documented as receiving one. You discover this when you exchange an authorization code and the response simply has no refresh_token field in it.
There is no documented self-service page that tells you in advance whether your app qualifies. The docs say only “If your application is authorized for programmatic refresh tokens, the following fields are returned…” The presence or absence of the field in the token response is the answer. That is a brittle way to learn something that determines whether your product can run unattended.
Three token models, three very different products
Standard 3-legged app
60-day access token. No refresh token documented. When it lapses, the member has to come back and authorise again. Fine for a tool a user opens; fatal for a background sync.
Approved MDP partner
Refresh token issued alongside the access token, documented as valid for a year. New access tokens can be minted server-side — until the refresh token itself expires.
Client credentials (2-legged)
The docs state the token “has a 30-minute lifespan and must be used immediately” — and that “2-legged OAuth authentication is not available for Marketing APIs.” Not an escape hatch.
The refresh token clock does not roll forward
This is the detail that catches teams who did get partner access, and it is stated explicitly:
The documentation walks through it: on day 59 you mint a fresh 60-day access token and the refresh token is down to 306 days. On day 360 both are five days from expiry, and the page is unambiguous about what happens next — “you must get your application reauthorized by the member using the authorization flow.”
So even the best case is a hard annual wall per member. Any product that promises continuous, hands-off operation has to be designed around a re-consent event it cannot avoid, and has to detect and handle that event gracefully rather than failing loudly in front of the customer.
Where LinkedIn token integrations actually break
- Day 60, no refresh token. The error-handling docs list “Expired access token” under 401. There is no warning beforehand.
- Day 365, refresh token gone. Documented as requiring member re-authorization. No documented way to extend it without consent.
- Scope change wipes existing tokens. “If you request a different scope than the previously granted scope, all the previous access tokens are invalidated.” A single added permission can log out your entire user base.
- Member revokes from privacy settings. The 401 table lists “The token has been revoked” and states the member must re-authenticate.
- LinkedIn revokes unilaterally. “LinkedIn reserves the right to revoke Refresh Tokens or Access Tokens at any time due to technical or policy reasons.” The documented expectation is that your product falls back to the standard OAuth flow and shows a login screen.
- The silent-refresh path has conditions. The re-authorization screen is only bypassed if the member is still logged in to LinkedIn and their current token has not already expired. Miss the window and there is nothing seamless about it.
- Refresh-token calls are themselves quota-limited. The Developer Portal now shows refresh-token usage against a daily per-app quota with a throttled or not-throttled state, resetting at 00:00 UTC.
A documentation trap worth knowing about
The sample JSON responses printed in LinkedIn’s own token documentation do not agree with the prose around them. One example shows expires_in as 86400 — one day — while the paragraph above it says 60 days. Another shows a refresh_token_expires_in value that only makes sense if the unit is minutes, despite the field being defined in seconds elsewhere on the page.
If you build your renewal scheduler by copying a sample payload instead of reading the prose, you will build it wrong, and the failure will not surface for weeks. Treat the written lifetimes as authoritative and validate against real responses from your own application before you ship anything that depends on them.
How this is approached properly
Establish which access programme the app is genuinely in — not which one the team assumes. Products, tiers and partner programmes each carry different scope and token consequences.
Confirm empirically whether a refresh token is being issued by inspecting a real token exchange for your own client, rather than trusting a tutorial written for a different access tier.
Map the product’s uptime promise against the token model. If the roadmap says “always-on sync” and the app sits on Model A, that gap has to be closed before launch, not after.
If refresh tokens are required, treat it as an access application. That means a use case LinkedIn will review, an app and Page in the right state, and a submission written to the standard the reviewer applies — the same discipline any LinkedIn access request needs.
Design the re-consent fallback regardless. LinkedIn documents revocation as always possible. A product that has no graceful re-auth path is one policy decision away from a support queue.
Why teams get stuck here
Steps 1, 2 and 4 are where most projects lose weeks. The token behaviour is a symptom; the underlying question is which access programme the application belongs to, and moving between programmes is a review process with its own requirements, not a toggle. Teams typically arrive at this point having already built and demoed the integration, which is the worst moment to discover that the architecture assumed a privilege the app was never granted.
This is the work I do for clients — reading the app’s actual access state, identifying which product or programme the required capability sits behind, and preparing the access request and supporting material so it is reviewed on its merits rather than bounced on avoidable gaps. Related reading on this site: LinkedIn Advertising API Standard Tier upgrades, Community Management API access tiers, and Sign In with LinkedIn and OpenID Connect. You can see the full list of what I help with on the services page.
All token lifetimes, error strings and programme restrictions above are quoted from LinkedIn’s official developer documentation on Microsoft Learn as published at the time of writing. Platform documentation changes; verify against the current pages before relying on any figure. This is independent technical and submission support — there is no affiliation with, partnership with, or endorsement by LinkedIn or Microsoft. No specific outcome can be guaranteed.