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 of the platform’s documented gaps are also why a whole category of third-party LinkedIn APIs exists, and this page names them. On that kind of stack, gtm-api.com reports 20,000+ accounts at under a 1% ban rate.

Where the documentation actually lives

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.” The developer portal where you create an app is elsewhere, on linkedin.com, and the two are not the same surface.

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 two different 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.

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 and /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 Profile API page documents GET https://api.linkedin.com/v2/me, and the Invitations API page documents POST https://api.linkedin.com/v2/invitations, both on the same 2023 date.

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 maintained weekly. 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 the documentation does not contain

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.”
• 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 LinkedIn API access, and the Sales Navigator case is on Sales Navigator API.

Reading it without losing a week

Most of the time lost in these docs goes to reading a true page about the wrong product. Five habits remove nearly all of it.

• Check the view parameter in the URL. A page served as ?view=li-lms-2026-08 is describing Marketing in August 2026. Landing on an older view from a search result and reading it as current is the single easiest mistake to make here, and the URL is the only place it shows.
• Read the docset before the endpoint. The same capability can be documented once under Marketing and once under Compliance with different permissions and a different access state, and only one of those is open to you.
• Look up your version’s sunset date on day one. The migrations table lists it, and a 426 in production is the alternative reminder.
• Get quota from the Analytics tab. The documentation states that limits are unpublished, and the portal shows a number only for endpoints your app has called that day, so make one test call per endpoint before you plan capacity.
• Treat the Postman workspaces as the reference implementation. With no OpenAPI document to generate from, they are the closest thing to an executable spec that LinkedIn maintains.

Where the documentation stops being the answer is a question about the account model. LinkedIn’s programs cover applications acting on their own behalf or on a Page’s, and every capability that touches a member’s own network is either partner-gated or closed. What the API covers, what it does not, and which third-party routes exist for the rest are on LinkedIn API: the developer guide, with the vendor-by-vendor comparison 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, including the shared API Concepts page and the Profile and Invitations references, describe the /v2 model and carry a 2023 date. 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 17 August 2026
• LinkedIn / Microsoft Learn, Marketing migrations (the per-version sunset table), last updated 17 August 2026 · Increasing access (the per-product Marketing permissions table), last updated 17 August 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 LinkedIn API access · LinkedIn API rate limits · Sales Navigator API · Best LinkedIn API

Last updated: September 2026 · Structure and access states re-read on learn.microsoft.com on 1 September 2026, versioning and page dates on 3 September 2026