The Official LinkedIn API vs Scraping APIs: What Developers Need to Know (2026)
Almost every developer who wants LinkedIn data starts at the same place: the official developer portal. And most of them leave confused. They came for profile data, or company firmographics, or a way to read job postings — and discover that the official API does none of those things for third parties. It is not a bug or a hidden endpoint you missed. It is the design.
This guide explains, neutrally and factually, what the official LinkedIn API actually offers in 2026, what it deliberately withholds, why LinkedIn keeps it that way, and where a public-data API fits as a practical alternative for the read use cases the official API was never built to serve. The goal is to save you the weeks people lose discovering these boundaries the hard way.
TL;DR: The official LinkedIn API is built for authentication and acting on behalf of a consenting member — sign-in, posting, ads, and partner-gated recruiter/marketing integrations. It offers no self-serve way to read a third party's profile or bulk company data; the consumer API returns only the logged-in member's own basics. For reading publicly available company, jobs, and profile data, a public-data API is the practical alternative — no partner approval, no OAuth. Neither is "better"; they solve different problems. Details and sources below.
What the official API actually offers
LinkedIn's developer platform is real and well-documented — it is just organized around member-authorized actions, not data retrieval. Here is the catalogue, split by how you actually get access:
| Product | What it does | Access |
|---|---|---|
| Sign In with LinkedIn (OpenID Connect) | Authenticate a user; read their own basic profile | Self-serve (app verification) |
| Share on LinkedIn | Post to the authenticated member's own feed | Self-serve (app verification) |
| Marketing Developer Platform | Advertising, Community Management, page & events data | Partner-gated (apply) |
| Sales Navigator (Sales Display API) | Profiles/accounts/messaging within Sales Navigator | Partner-gated |
| Talent Solutions (Recruiter System Connect, Apply Connect) | ATS sync, job posting, apply flows | Mostly partner-gated |
| Learning API | Course catalog and learning data | Partner-gated |
Notice the pattern. The self-serve tier does two things: log a user in, and let them post. Everything with real data behind it sits inside a partner program. And even those partner programs are scoped to the accounts, pages, and campaigns your client administers — not to the open graph of members and companies.
One 2026 housekeeping note if you are reading older tutorials: LinkedIn retired the legacy r_liteprofile and r_emailaddress scopes. Current apps use OpenID Connect scopes (openid, profile, email, w_member_social) and read the signed-in member's basics from the /v2/userinfo endpoint.
The data you cannot get officially
This is the part that surprises people, so let us be exact about it. Through the official API, a general developer cannot:
- Read a third party's profile. The consumer API returns only the authenticated member's own profile — name, headline, photo, email — from
/v2/userinfo, and only after that member consents. There is no endpoint for looking up someone else. - Pull bulk company firmographics. There is no open firmographic-lookup API. Company and page data lives inside the partner-gated Marketing programs and is tied to pages your client already administers.
- Aggregate or resell member content. LinkedIn's API Terms of Use explicitly forbid aggregating profile content, storing it beyond narrow limits, and "selling access to an aggregated collection of Member profiles" — and separately bar using any content obtained through scraping or crawling.
The one recent exception proves the rule. Under the EU's Digital Markets Act, LinkedIn added a Member Data Portability API — but it only lets a member (or an app that specific member authorizes) export that member's own data. It is a compliance obligation to the individual, not a third-party lookup product. In short: if the data belongs to someone else and they have not personally authorized your app, the official API is a closed door.
Why LinkedIn keeps it closed
There are two honest reasons, and they reinforce each other.
Privacy and control. LinkedIn publicly frames the restriction as protecting members and keeping control over where member data lives. It pairs that stance with active legal enforcement and technical anti-bot defenses. Whatever one thinks of the framing, it is the stated rationale and it is consistent with how the platform behaves.
Monetization. LinkedIn already sells access to its data — through Recruiter, Sales Navigator, and Talent and Learning subscriptions. Those are large, enterprise-priced products. An open profile or firmographic API would compete directly with them, so the data path is kept inside paid tools and negotiated partner agreements rather than a public endpoint. This is not unique to LinkedIn; it is the standard playbook for a platform whose data is the product.
The partner programs, and their bar
If your use case genuinely fits — you are building martech that manages clients' ad campaigns, or an ATS syncing with Recruiter — the partner programs are the right road. Just go in with realistic expectations about the bar:
- A verified LinkedIn Company Page is a prerequisite before you can even create a qualifying app. You supply legal entity details, a business email, a website, and a privacy policy.
- Two access levels exist — a broader "Partner" tier for verified platforms with higher rate limits, and a more limited "Access" tier for individual companies.
- Review is use-case-based. You apply through the developer portal, describe a legitimate business purpose, and often submit a demo. Applications that look like a data-resale or a LinkedIn look-alike are the ones that stall.
Reported approval timelines run from a few weeks in the best case to several months with back-and-forth — figures that circulate in third-party integration guides rather than official LinkedIn commitments, so treat them as ballpark. The takeaway is simply that the partner path is a real business relationship, not a signup form, and it is scoped to acting for clients — not to open data access.
The practical alternative: public-data APIs
Now the other side. A large share of "I need LinkedIn data" is really "I need to read publicly visible information at scale" — a company's size and industry, the roles it is posting, the public basics of a profile. The official API was never built for that, and the partner programs do not cover it. This is the gap a public-data API fills.
The model is different in kind. Instead of authenticating as a member and acting on their behalf, a public-data API reads publicly available pages and returns them as structured JSON. With Serpent's LinkedIn API, you send a public company slug, a job keyword, or a profile URL and your own API key — no LinkedIn login, cookie, or OAuth flow on your side — and get back clean data:
| Need | Official API | Public-data API |
|---|---|---|
| Log a user in / post as them | ✅ Yes (self-serve) | ❌ Not its job |
| Manage a client's ads or ATS | ✅ Yes (partner) | ❌ Not its job |
| Read public company firmographics | ❌ No | ✅ Yes |
| Read public job postings | ❌ No | ✅ Yes |
| Read public profile basics | ❌ Third parties: no | ✅ Best-effort |
The two are not competitors so much as tools for opposite jobs. One acts on behalf of a member; the other reads what is already public. If you have spent a week fighting the partner-application process only to realize you never needed to post or manage anything — you just needed to read public data — the public-data route was the answer all along.
How to choose between them
Skip the philosophy and answer one question: are you acting for a member, or reading public data?
- Choose the official API if you need to authenticate users, post on their behalf, or programmatically manage the ad campaigns, pages, or recruiter workflows of clients who have authorized you. That is exactly what it is for, and nothing else does it legitimately.
- Choose a public-data API if you need to read publicly available company firmographics, job postings, or profile basics — for enrichment, lead scoring, market research, or sourcing — without becoming an approved LinkedIn partner.
- Sometimes you need both. A product might sign users in with the official API and enrich accounts with a public-data API. They coexist cleanly because they never overlap.
Just need to read public data? Create a key in under a minute — new accounts include 10 free Google searches to explore the platform. Grab a free key and pull company, jobs, or profile data with one request.
A note on compliance
Choosing a public-data API changes the technical model, not your responsibilities. A public-data API accesses only publicly available information and uses no login or credentials — which is a meaningfully cleaner posture than automating a logged-in account. But "public" is not "unrestricted": LinkedIn's terms, your jurisdiction, and privacy law such as GDPR and CCPA still govern how you may collect and use the data, and personal data in particular carries obligations regardless of where it came from.
We wrote a careful, neutral companion piece on exactly this — the legal landscape around LinkedIn data in 2026, covering the hiQ and Van Buren decisions, terms-of-service versus computer-access law, and where privacy regulation fits. Read it before you build anything at scale, and treat compliance as your own decision rather than something any API waves through.
Read public LinkedIn data without the partner gauntlet
Company firmographics, public job postings, and profile basics as structured JSON — no partner application, no OAuth, no login. One REST endpoint and one key, pay-as-you-go with no subscription.
Get Your Free API KeyExplore: LinkedIn API · Social Media APIs · Pricing
FAQ
Does LinkedIn have an official API?
Yes, but it is scoped to specific jobs, not general data access. Self-serve products cover authentication (Sign In with LinkedIn using OpenID Connect) and posting to the authenticated member's own feed (Share on LinkedIn). Everything richer — advertising, page management, Sales Navigator, and recruiter/ATS integrations — lives in partner programs you must apply to and be approved for. There is no self-serve official API for reading arbitrary third-party data.
Can I get profile or company data from the official LinkedIn API?
Not for third parties. The consumer API returns only the authenticated member's own basic profile (name, headline, photo, email) from the /v2/userinfo endpoint, and only with that member's consent. There is no official API that lets a general developer pull a stranger's full profile or bulk company firmographics — that data path is deliberately closed, and LinkedIn's API Terms of Use forbid aggregating or reselling member profile content.
Why is the LinkedIn API so restricted?
LinkedIn frames the restriction as protecting member privacy and keeping control over where member data lives. Commercially, it also monetizes data access through paid enterprise products — LinkedIn Recruiter, Sales Navigator, and Talent and Learning subscriptions — rather than through open data APIs. An open profile or firmographic API would compete with those products, so access is kept inside partner agreements and paid tools.
What is the alternative to the official LinkedIn API?
For reading publicly available LinkedIn data — company firmographics, public job postings, and public profile basics — the practical alternative is a public-data API that returns those pages as structured JSON without requiring you to become an approved LinkedIn partner. You send a public URL or identifier and get data back, with no LinkedIn login or OAuth on your side. It solves a different problem than the official API, which is built for acting on behalf of a consenting member.
Is using a LinkedIn data API allowed?
A public-data API accesses only publicly available information and uses no login or credentials, which keeps the integration clean. But "public" is not the same as "unrestricted": LinkedIn's terms, your jurisdiction, and privacy law still apply to how you collect and use the data — especially personal data. Treat compliance as your own responsibility rather than something any tool guarantees. See our companion guide on the legal landscape for the details.
