LinkedIn API endpoints: the 7 official groups and who actually gets access

You register a LinkedIn developer app, request the Sales Navigator API so your tool can pull lead data, and wait. Weeks later the reply is the one thousands of developers get: Sales Solutions access is a commercial partnership reserved for established CRM vendors, not something you apply for. And the endpoints you actually needed, reading a profile by URL, running a people search, messaging someone you have never met, were never on the menu for third parties at all. You did not hit a rate limit or a paperwork snag. You hit the design.

That gap, between the endpoint list every article hands you and the access almost nobody gets, is what this reference is built around. First the seven official endpoint groups in one table, with the tier and the realistic approval odds for each. Then the honest section nobody writes: what you actually do when the answer is "you will not get approved," which is the answer for the majority of use cases.

The 7 official LinkedIn API endpoint groups

Every third-party thing you can legitimately call maps to one of these families. The single most useful column is not the endpoint name, it is who gets approved.

Read that table twice. Six of the seven groups are gated, and the gate on the bottom three is a signed commercial partnership, not a form. "Approval odds" for a solo developer or an early-stage SaaS on those three is effectively zero, and saying so plainly saves you weeks.

A few rows are worth expanding, because they are the ones people misread.

Sign In with LinkedIn is the one endpoint anyone can get

OpenID Connect via LinkedIn is genuinely open. You register an app, request the openid, profile, and email scopes, and you can authenticate a user and read their name, headline, photo, and email. That is the whole surface, and it is a real, useful surface for building a login button.

What it is not is a data endpoint. It returns the profile of the person who just signed in and consented, and nothing else. There is no version of this that lets you read an arbitrary member's profile by URL. When a guide implies "just use Sign In with LinkedIn to pull profiles," it is describing something the scope does not permit.

Marketing and Pages: hard, but genuinely possible

The Marketing Developer Platform is the one gated tier a normal company can actually clear. It uses a two-step vetting model: a Development tier that lets you build and test against a hard cap, posting to at most five ad accounts while reading from any number, and a Standard tier you request once your integration meets the business-line requirements and LinkedIn approves the upgrade (LinkedIn Marketing API access tiers, Microsoft Learn, as of 2026). The Advertising, Organization, Share, and UGC endpoints all sit in this family.

The bar is a real product with an active user base and a marketing use case that complements LinkedIn's ad business rather than competing with it. Social media management tools, ad-reporting platforms, and page-management vendors clear it. The review runs weeks to months, rejection is common for thin applications, and LinkedIn states plainly that it can decline an upgrade even when you meet the stated minimums. If your use case is "read profiles to build a prospecting list," this tier will not approve you, because that is not a marketing use case in LinkedIn's sense.

Each endpoint in this family also demands specific OAuth scopes in the access token, and the scope is granted only after the tier is. Publishing needs w_member_social, ad reporting needs r_ads, and page management needs r_organization_social or w_organization_social. You cannot request the scope first and back into the access; the tier approval is the thing that unlocks the scope, which is why "just add the scope" is not a workaround when your app has not cleared review.

Sales Navigator, Talent, and Compliance are partner contracts

The Sales Solutions and Talent Solutions APIs are the ones most people are actually hoping for when they search "LinkedIn API," and they are the least reachable. Access is not a developer application. It is a commercial partnership, usually reserved for established CRM and ATS vendors, negotiated and contractual. The Compliance API is narrower still: it exists so regulated firms can archive employee activity for legal reasons, and access tracks that mandate.

There is no self-serve path to any of the three. If you are not a funded vendor with a signed agreement, treat them as closed. This is the single biggest gap between what the SERP implies is available and what you can call.

For the money side of all this, whether the partner APIs cost anything and what the tiers actually price at, see the companion piece on whether the LinkedIn API is free.

Rate limits: the part the endpoint tables leave out

LinkedIn does not publish one universal number, and it will not tell you your ceiling until you already hold the app. Every approved app carries two daily throttles at once, both resetting at midnight UTC, and breaching either returns an HTTP 429 (LinkedIn rate-limit docs, Microsoft Learn, as of 2026).

You do not read these numbers off a public page. You look up your own app's allotment in the Developer Portal Analytics tab, and Developer Admins get an email only once an app crosses 75 percent of an endpoint's quota. So "which endpoints" is the wrong first question. Even inside an approved tier, your ceiling is a per-app and per-member budget you plan around, not a route you call freely.

This matters because the same discipline shows up on the other side of the fence. When you act through a real account rather than a partner app, the account has its own daily budget, and blowing through it is what gets accounts restricted. Pacing is not a partner-API concept you can leave behind by going around the API.

What you actually do without partner approval

Here is the honest map for the common case: you searched "LinkedIn API endpoints" because you want to find people, understand a company, or run outreach, and you have just learned that the partner API will not approve you for any of that. You have three real lanes, and they are not equally exposed.

The lanes stack. Most of the work, the finding and qualifying and drafting, lives in the public lane and needs nothing connected. Only the final send needs a real account, and it should be one you control and pace.

Public data: the lane that needs nothing

Public LinkedIn pages, profiles, company pages, posts, job listings, are readable the same way a browser reads them, without acting as anyone and without a connected account. This is where finding and qualifying should happen. A free LinkedIn people search tool runs entirely on this lane: you get results with nothing signed in and nothing at risk. It is not the partner API and it is not pretending to be. It is public data, read as public data.

The important distinction from the third-party lane below: reading a public page from a server does not operate an account, so there is no account to expose.

The unofficial-API lane, and its real cost

A category of vendors sells what they call a LinkedIn API by having you hand over a session, then replaying that session from their servers to reach data the partner API will not give them. Unipile is the cleanest example of this model, and it is a legitimate product for what it is. The tradeoff is structural: your account is now active from an IP that is not yours, on a schedule you did not set, and that mismatch is one of the more legible automation signals there is. The comparison of that model against a public-first one is laid out in the BeReach vs Unipile breakdown.

This lane works. It is also where the account risk concentrates, because someone else is holding and replaying your session. If you take this route, know exactly what you are trading.

The developer route that does not put an account on the line

BeReach is built around the map above rather than against it. The entire find, qualify, and draft workflow runs on the public lane, with nothing connected. A LinkedIn session is required at exactly one point, the real outreach send, and not one step before it. That is what cookieless until outreach means, and against this particular topic it lands differently: the partner API forces a choice between a months-long review you probably will not pass and handing your session to a vendor who replays it, while reading public pages needs neither, because finding, qualifying, and drafting never required an endpoint or an account to begin with.

For developers, that surfaces two ways. There is a REST layer of 135 operations behind a BEREACH_API_KEY, documented at the BeReach API landing, which covers the public find and qualify operations plus the paced account actions. And there is a 33-tool MCP connector at mcp.bereach.ai that runs inside Claude, so an agent can do the finding and drafting conversationally and hand you drafts to approve. The setup is in the docs for running BeReach from Claude, and the deeper walkthrough is in the guide to the LinkedIn MCP server for Claude.

The account actions that do need a session are paced on purpose: conservative daily budgets for visits, invitations, and messages, sitting under LinkedIn's own weekly invitation ceiling. That is not a throttle we advertise as a feature, it is the same rate discipline the partner API enforces, applied to the one lane that touches your account. The edge is less exposure, not more automation.

The short version

The seven official endpoint groups are real, but six of them are gated and three of those are commercial partnerships you will not reach as a small builder. The endpoints most people want, arbitrary profiles, connections, search, and messaging, are not available to third parties on any tier. The workable path for finding, qualifying, and drafting is the public-data lane, which needs no approval and no connected account, with a real session reserved for the send itself. Build around that split and the approval wall stops being your problem.