LinkedIn’s API documentation is hosted on learn.microsoft.com, and it is six separate docsets rather than one reference: Consumer, Compliance, Learning, Marketing, Sales and Talent. Each business line versions its own APIs on its own schedule, so a version number, a base path and a support window all depend on which set you are reading.

That structure is the first thing to learn, because a page answers correctly for its own product and misleads for every other one. Two limits the docs state outright, no open lookup of another member’s profile and no browsing of anyone else’s connections, are also why a whole category of third-party LinkedIn APIs exists, working through a LinkedIn account you connect. On that stack, gtm-api.com runs 20,000+ accounts with under 1% of them ever restricted.

How LinkedIn’s API documentation is organized

LinkedIn’s developer material lives in two places that do different jobs. The documentation describes the APIs: what each endpoint does, which permission it needs and which version it belongs to. The developer portal on linkedin.com is where you create an app, request products and read your own quotas, and none of that is in the documentation. The documentation itself is six docsets, one per business line, with a shared section above them and a version history inside each, and most of the confusion people meet comes from reading one docset’s rule as if it applied to all six.

The canonical home is learn.microsoft.com/en-us/linkedin/, and its own index page states the arrangement: “LinkedIn’s home for API documentation for all LinkedIn business lines. Our API documentation is organized by business lines covering Consumer, Compliance, Learning, Marketing, Sales, and Talent Solutions.”

Above the six sits a shared section that most developers need before any of them: Get API Access, Authentication, API Concepts, Development Resources, Best Practices and the Breaking Change Policy. It is the part that reads like a platform reference, and it is also the part that has aged worst, which the section on the two-speed docs gets to.

The whole thing is larger than it looks from the index. Walking the five product tables of contents on 1 September 2026 returns 711 entries between them, which is why searching inside one docset beats browsing across all of them.

Reading a version and its two support windows

Versioned APIs arrived in June 2022 on a new base path, and the version travels in a request header. LinkedIn’s Marketing versioning page gives the format in one line: “Include a request header with the key ‘Linkedin-Version’ and set the value to the version (format: YYYYMM) to correspond with the documentation version you are referencing.”

There is no implicit latest. The Marketing versioning page carries a heading that says so, No unversioned calls, and under it the rule: “An error response is returned when the version header is missing in the request.” Send a version that has passed its sunset and you get a dedicated status code, 426, which the error-handling page describes as a deprecated version header.

The support window is where the business lines separate, and this is the detail that gets copied wrongly between projects.

The view parameter is also where a stale page gives itself away. A search result often lands on an older version of a page, and ?view=li-lms-2026-10 in the address, Marketing as of October 2026, is the only place that shows which one you are reading.

Marketing’s own words for the cadence: “Our versioned API releases follow a monthly cycle. These API versions are supported and stable for a minimum of one year before sunset.” Talent’s, for the same idea: “LinkedIn supports each version for a minimum of 2 years from its release date.” Both are minimums, and LinkedIn keeps room to move inside them: it “reserves the right to release a patch version to any API if required for any critical security, privacy issues, or bug fixes.”

Migration between versions is usually trivial. “To migrate your app from an older version to a later version, simply update the older version’s YYYYMM formatted value in the header to the newer version’s value.” The work is in noticing the deadline, and the deadline is on the migrations page, which lists every Marketing version against its sunset date.

The /v2 versus /rest split and the pages that still disagree

Versioning came with a new base URL. LinkedIn’s Talent versioning announcement puts the old and the new side by side, https://api.linkedin.com/v2/ against https://api.linkedin.com/rest/, and gives the advice that ages well: “In order to facilitate easy migration, you should make the base URL and version header configurable modifications to your solution.”

The trap is that both paths are still documented, on pages that look equally current. The shared API Concepts page, the one a developer reads first, still describes the platform as basePath: /v2 and adds “The /V2 basePath is used for most LinkedIn API calls.” It was last updated in 2023. The Invitations API page documents POST https://api.linkedin.com/v2/invitations on the same 2023 date, and the Profile API page, updated in April 2026, still documents GET https://api.linkedin.com/v2/me.

The header name is inconsistent too, across pages that are all live. Marketing’s versioning page spells it Linkedin-Version. The shared error-handling page, describing the 426 response, calls it X-LinkedIn-Version. Take the spelling from the docset whose API you are calling and confirm it against a real request, because no page reconciles the two.

The two-speed docs

Every page on learn.microsoft.com prints its own last-updated date at the foot, and the dates across the set tell you something no single page does. The versioning and access machinery is updated month by month. The conceptual foundation under it has not moved in three years.

The practical rule that falls out of it: a page dated 2023 is describing a model that predates versioning, and a page dated this year is describing the current one. When the two conflict, the recent page wins, and the 2023 page is usually right about the endpoint it documents and wrong about the platform around it.

What you won’t find in the LinkedIn API docs

Four absences shape a LinkedIn integration as firmly as anything the docs actually say. Three of them are stated outright. The fourth is visible only by walking the tables of contents.

• No published rate limits. The rate-limiting page says it in one sentence, “Standard rate limits are not published in documentation”, and sends you to the Developer Portal’s Analytics tab, which shows a limit only for endpoints your app has already called today. The full picture, including what LinkedIn does publish, is on LinkedIn API rate limits.
• No consolidated permissions reference. Scopes are split between the Open Permissions table on Get API Access and a per-product table inside Marketing, and the authorization page explains why a static list would not help: “The scopes available to your app depend on which Products or Partner Programs your app has access to.”
• No machine-readable description. LinkedIn publishes no OpenAPI or Swagger document anywhere in the six docsets. The substitute it offers is a set of public Postman workspaces, plus two official client libraries, in JavaScript and Python, that deliberately do not wrap individual APIs. LinkedIn’s own explanation for why they exist at all is candid: “Nearly all of LinkedIn’s APIs are built on the Rest.li framework with additional LinkedIn-specific details, which results in a robust yet complex protocol that can be challenging to implement correctly.” With no OpenAPI document to generate from, the Postman workspaces are the closest thing to an executable spec that LinkedIn maintains.
• No general member search. Walking all five product tables of contents turns up no search endpoint over members. The one search-shaped API in the Marketing set is People Typeahead, and it is scoped to a Page’s own followers: “Pages (via Page Admins) can search for Page followers by keyword or vanity URL”, returning up to 10 profiles.

Two more limits are stated plainly enough to quote in full. Between them they close profile lookup and graph traversal, the two capabilities a plan drafted from the docs tends to assume. On profiles: “To retrieve another member’s profile, you will need access to the Person ID, available only via certain limited access APIs and subject to member privacy settings.” On the graph: “You cannot ‘browse connections.’ That is, you can only get the connections of the user who granted your application access.”

The access page frames the whole platform in one sentence, and it is the sentence to read before planning anything: “Most permissions and partner programs require explicit approval from LinkedIn. Open Permissions are the only permissions that are available to all developers without special approval.” There are three Open Permissions in total. Which programs still take applications, and which are shut, is on How to get official LinkedIn API access, and the Sales Navigator case is on Sales Navigator API.

The documentation covers what an app can do for the member who signed in, for a Page that member manages, or for itself. Anything that reaches into other members’ networks, searching people, inviting them, messaging them, is partner-gated or closed, and the docs have no answer for it. For that half, teams use a third-party API that acts through a LinkedIn account they connect: what each route covers is on LinkedIn API: the developer guide, and the vendors side by side on Best LinkedIn API.

Frequently Asked Questions

Where is the LinkedIn API documentation?

On learn.microsoft.com/en-us/linkedin, not on linkedin.com. It is organised as six business lines, Consumer, Compliance, Learning, Marketing, Sales and Talent, plus a shared section covering access, authentication, API concepts and the breaking change policy. The developer portal where you create an app and read your quota is a separate surface on linkedin.com.

What is the LinkedIn-Version header?

It is how a request selects an API version, and it is required on every versioned call. The value is the version in YYYYMM format, matching the documentation version you are reading. LinkedIn applies no default, so a missing header returns an error, and a version past its sunset returns a 426. Note that one shared error-handling page spells the header X-LinkedIn-Version, so confirm the spelling against the docset you are calling.

How long is a LinkedIn API version supported?

It depends on the business line. Marketing publishes a version monthly and supports each one for a minimum of one year. Talent supports each version for a minimum of two years and does not release on a fixed monthly cycle. Both are minimums, and LinkedIn reserves the right to ship a patch version inside the window for security, privacy or critical bug reasons. The Marketing migrations page lists every version against its sunset date.

Does LinkedIn publish an OpenAPI spec or official SDKs?

No OpenAPI or Swagger document appears anywhere in the six docsets. LinkedIn does maintain public Postman workspaces and two official client libraries, in JavaScript and Python, and it says plainly that those libraries do not support specific APIs. They abstract the Rest.li protocol so you can build your own higher-level client on top.

Why does the LinkedIn documentation show /v2 on some pages and /rest on others?

Because both are real and the docs were never fully rewritten. Versioned APIs launched in June 2022 on api.linkedin.com/rest with a version header, while unversioned endpoints stayed on api.linkedin.com/v2. Several still-published pages describe the /v2 model: the shared API Concepts page and the Invitations reference carry a 2023 date, and the Profile reference still shows /v2/me after an April 2026 update. Take the base path from the endpoint’s own page, and check that page’s date.

Sources & Further Reading

• LinkedIn / Microsoft Learn, LinkedIn API documentation index (the quoted six-business-line arrangement), read 1 September 2026
• LinkedIn / Microsoft Learn, Marketing API versioning (the quoted header format, the No unversioned calls rule, the monthly cadence and one-year minimum, the patch-version clause and the migration instruction), last updated 15 October 2026
• LinkedIn / Microsoft Learn, Marketing migrations (the per-version sunset table), last updated 15 October 2026 · Increasing access (the per-product Marketing permissions table), last updated 19 October 2026
• LinkedIn / Microsoft Learn, Talent API versioning (the quoted two-year minimum, the version list with its gaps and the 202508.02 patch version), last updated 2 September 2026 · Versioning announcement (the old and new base URLs, and the quoted configurable-migration advice)
• LinkedIn / Microsoft Learn, Get API access (the quoted approval statement, the three Open Permissions, and the closed state of Compliance), last updated 26 June 2025 · Authorization code flow (the quoted statement that available scopes depend on granted products)
• LinkedIn / Microsoft Learn, Rate limiting (the quoted statement that standard rate limits are not published, and the Analytics tab instruction), last updated 20 August 2025 · Error handling (the 426 deprecated-version response and the X-LinkedIn-Version spelling)
• LinkedIn / Microsoft Learn, API concepts (the quoted /v2 base path, last updated 8 May 2023) · Profile API (the quoted Person ID restriction) · Invitations API (the /v2 path) · Connections API (the quoted browse-connections prohibition)
• LinkedIn / Microsoft Learn, API client libraries (the two official SDKs, the statement that they do not support specific APIs, and the quoted Rest.li explanation), last updated 30 March 2023 · Postman workspaces
• LinkedIn / Microsoft Learn, People Typeahead API (the quoted follower-scoped search and the 10-profile cap) · Sales Solutions overview (the statement that new SNAP partners are not being accepted)
• Related: LinkedIn API: the developer guide · How to get official LinkedIn API access · LinkedIn API rate limits · Sales Navigator API · Best LinkedIn API

Last updated: October 2026 · Definitions and benchmarks verified at time of publication