LinkedIn API in 2026: Three Ways to Get LinkedIn Data, and What Each Costs

Almost every tool that promises "LinkedIn data" through code is, under the hood, one of three things: an official LinkedIn API, an unofficial scraping API, or a B2B enrichment API that sells LinkedIn-style fields without ever calling LinkedIn directly. The labels in the marketing pages do not always make the distinction, but the consequences for cost, compliance, and reliability are very different.

This guide lays out the three categories side by side. What each one actually returns, what it cannot return, what LinkedIn's terms allow, and what a realistic SDR or recruiter workflow looks like when calling each from Python or Node in 2026.

What is the LinkedIn API, and does LinkedIn have a free one

The LinkedIn API is not one interface. It is a catalogue of first-party endpoints split across six business lines, each with its own approval route and its own scopes, and none of them returns the profile of a person who has not authorised your app. That single sentence settles most of the questions people arrive with.

Does LinkedIn have a free API?

Yes, and it is narrower than the word free suggests. A new app you create in the developer portal gets two products by default: Sign In with LinkedIn using OpenID Connect, and Share on LinkedIn. Between them they carry four scopes, and those four scopes define the whole of the free surface.

Read the third column twice. Every free scope is about the person sitting in front of the consent screen. There is no free scope, and no paid self-serve scope either, that takes a profile URL and gives you back that person's details. Everything beyond this table runs through a partner programme, and the sections below say which one and what it asks for.

Chapter 1: The three categories at a glance

Across the 2026 landscape, every API that claims to extract LinkedIn data falls into one of three buckets. The distinction matters because it changes what data you get, what risk you take on, and what the contract looks like.

Official LinkedIn APIs. Documented endpoints under api.linkedin.com, gated behind LinkedIn's partner program. Categories: Marketing Developer Platform, Sales Solutions API, Talent Solutions API, Sign In with LinkedIn, Share on LinkedIn. Compliant by definition. Narrow in scope: cold profile lookup is not on the menu.

Unofficial scraping APIs. Third-party services that operate browser farms or scraping pipelines against LinkedIn under the hood, then expose the result as a clean REST API. They come in three shapes: standalone LinkedIn scraping APIs, LinkedIn presets shipped on general-purpose scraping platforms, and the many LinkedIn endpoints resold through API marketplaces. Broad scope. Each call is a violation of LinkedIn's Section 8.2 even if you never see the violation in the request log.

B2B enrichment APIs. Services that aggregate identity, contact, and firmographic data from public sources, opt-in databases, and partnerships, then return LinkedIn-style fields through their API. Derrick sits in this category. The API never calls LinkedIn at all. The data is "LinkedIn-style" but sourced from outside LinkedIn. Compliance posture is on the vendor's data sources, not on LinkedIn's ToS.

For the broader picture on extraction methods (extensions, scrapers, APIs, MCPs), the 2026 LinkedIn data extraction guide places the API question inside the wider toolbox. This article zooms in on the API layer.

Chapter 2: Official LinkedIn APIs - what you can and cannot do

LinkedIn ships several first-party APIs. Each is gated behind a different application track and each exposes a narrow surface that LinkedIn explicitly endorses.

Marketing Developer Platform. For ad tech and analytics integrations. Returns campaign performance, ad creative metadata, account spend, lead-gen form responses. No profile fields, no company-employee lookup. Application: roughly 2-6 weeks for approval, requires a working ad-tech use case.

Sales Solutions API. For CRM bidirectional sync with Sales Navigator. Returns saved-search alerts, account/lead list metadata, CRM sync hooks. Profile and company fields are limited to what the user already saved in Sales Navigator. Available only to enterprise Sales Navigator customers.

Talent Solutions API. For ATS integrations. Returns LinkedIn Recruiter project metadata, candidate pipeline data, job posting CRUD. No cold profile search across LinkedIn at large.

Sign In with LinkedIn / Share on LinkedIn. For consumer-facing apps that need OAuth or one-click sharing. Returns the signed-in user's profile data only, not anyone else's.

The pattern is clear: official LinkedIn APIs serve LinkedIn's commercial ecosystem (ads, ATS, CRM partners). They do not serve the most common prospecting or recruiting workflow, which is "given a name and a company, return their LinkedIn URL and email". That workflow lives outside the official API.

Pricing model: usage-based on top of a base partnership contract. The base contract is typically negotiated annually with LinkedIn account managers; published pricing does not exist for the deeper APIs.

Products, scopes and what each one actually returns

The table LinkedIn does not publish in one place. It is the fastest way to find out whether your use case needs a partnership before you spend three weeks writing an application.

LinkedIn profile API: what it actually returns

There is no endpoint called the LinkedIn profile API in the sense most people mean it. The Consumer line returns the profile of the member who authorised your app, through the openid and profile scopes, and stops there. Passing someone else's profile URL to an official endpoint returns an authorisation error, not a smaller payload. If your product needs to resolve arbitrary people, the official catalogue is the wrong catalogue, and chapters three and four cover what is left.

LinkedIn jobs API: what it actually returns

Job posting lives in Talent Solutions, which is a partner programme rather than a self-serve product. Approved partners can create, update and close job posts, and can move candidates between LinkedIn and an applicant tracking system. Reading the public job board at volume is not part of it. A job aggregator that shows LinkedIn listings is either an approved Talent partner or is getting that data somewhere other than the official API.

What the official LinkedIn API actually covers, product by product

Most guides describe the LinkedIn API as a single thing. It is not. LinkedIn publishes a product catalogue split across six business lines, and each line has its own approval route, its own scopes, and its own idea of what data you are allowed to touch. Knowing which line your use case falls into is the difference between a two-day integration and a three-month application that gets declined.

Read that table with a prospecting hat on and one thing jumps out: none of these lines exposes cold profile lookup. The Consumer line returns the profile of the member who just authorised your app, and nothing else. The Sales line surfaces Sales Navigator data back into a CRM your customer already pays for. The Talent line moves candidates between LinkedIn and an applicant tracking system. There is no endpoint anywhere in the official LinkedIn API where you pass an arbitrary profile URL and receive that person's details.

This is deliberate, and it dates back to 2015, when LinkedIn closed the open public API that had let any developer read profile data. Everything since has been gated behind partnership. If a vendor tells you their product is powered by the official LinkedIn API and also returns cold profile data, one of those two claims is wrong.

What you can and cannot do, side by side

Collapsing everything above into one table makes the decision fast. Read the middle column first: it is the one that usually ends the discussion.

The pattern is consistent. The official route is safe and narrow. The scraping route is broad and borrowed. The enrichment route is broad and owned, which is why it is the one that survives contact with a procurement review. If you want the mechanics of the middle column in more detail, our guide to LinkedIn limits and what triggers them covers the account side, and how to choose a LinkedIn scraper compares the tooling.

Chapter 3: Unofficial scraping APIs - broad scope, sharp tradeoffs

This is the category most developers find first when searching "linkedin data extraction api". The product looks like a normal REST API: pass a LinkedIn profile URL, get back a JSON payload of structured fields. Under the hood, the vendor runs a fleet of headless browsers, residential proxies, and CAPTCHA solvers against LinkedIn at scale. The request happens server-side; you never see the scraping layer.

What they return. Full profile fields (headline, work history, education, skills, recommendations), company pages, employee lists from a company URL, sometimes Sales Navigator search results.

How they price. Per-request, typically $0.005 to $0.05 per profile depending on the depth and the vendor. Bulk plans drop the unit cost to $0.001-0.005 in volume. Entry tiers are $50-200/month for 5,000-50,000 calls.

The compliance reality. Three things to be honest about with the team or the legal counsel before adopting one:

1. LinkedIn ToS Section 8.2. Each call to the unofficial API is, transitively, an automated access to LinkedIn. The violation does not show up in your request log because the violation happens on the vendor's infrastructure. The legal exposure does not disappear; it shifts to whoever is operating the scraper farm.
2. The hiQ Labs v. LinkedIn line of cases. The Ninth Circuit's 2017-2022 rulings clarified that scraping publicly accessible data is not a violation of the Computer Fraud and Abuse Act. They did not legalize automated access against LinkedIn's terms. LinkedIn can still cancel partnership relationships and pursue breach of contract claims even if criminal CFAA exposure is reduced.
3. GDPR. Even if the scraping is upstream of you, you are still a data controller (or a joint controller) when you ingest the result and use it for prospecting. The lawful basis question (legitimate interest, opt-out mechanism, retention policy) applies regardless of how the data was collected. The GDPR data enrichment guide walks through this for B2B teams.

The reliability reality. LinkedIn's bot detection has gotten sharper every year since 2023. Vendors regularly hit rough patches where the API returns degraded or stale data while their scraping farm rotates IP pools. Schedule on the assumption that any given week may have a 24-72 hour quality dip.

Chapter 4: B2B enrichment APIs - the workhorse for prospecting in 2026

This category is where the bulk of SDR, recruiter, and growth-team API traffic actually lives in 2026. A B2B enrichment API takes an input (name + company, email, LinkedIn URL, domain) and returns an enriched record (LinkedIn URL, headline, current company, role, location, email, phone, firmographic fields) sourced from the vendor's data partnerships.

The vendor is not scraping LinkedIn. The data has overlap with LinkedIn because both LinkedIn and the vendor pull from the same underlying public sources, opt-in databases, business registrations, and B2B partnerships. Hit rates are high because the same person tends to appear in many of those sources.

What you get. The fields that matter for cold outreach: LinkedIn URL, name, headline, current company, role, location, email (verified or unverified), phone (cell or direct line where the source supports it), company size, industry, technographics (sometimes).

What you do not get. Fields that only live inside LinkedIn's social graph: connections list, recent activity feed, recommendations, group memberships, exact hire date inside a company. If any of these are central to the workflow, the unofficial scraping API category covers more of them.

Pricing model. Per-credit, with most vendors charging different credit amounts for different field types. Profile lookups: 1-2 credits. Email lookups: 5-10 credits. Phone lookups: 5-25 credits. Entry tiers run $20-100/month for 5,000-20,000 credits, scaling linearly to enterprise tiers at $1,000-10,000/month.

API surface. Most B2B enrichment APIs converge on a similar shape:

GET /v1/profile?linkedin_url=...
GET /v1/profile?name=...&company=...
GET /v1/email?linkedin_url=...
GET /v1/phone?linkedin_url=...
POST /v1/bulk { "rows": [...] }

A single integration takes a few hours: read the OpenAPI spec, write a wrapper, hook into the prospecting pipeline. Same wrapper works across vendors with light adapter changes.

A real workflow in code. Here is the Python-equivalent skeleton for a Tuesday morning prospecting block. The team has a sheet of 200 target accounts and needs the head of sales at each, with email, before noon.

import requests, csv

API_KEY = "..."
BASE = "https://api.example.com/v1"

def find_decision_maker(company):
    titles = ["Head of Sales", "VP Sales", "CRO", "Sales Director"]
    for title in titles:
        r = requests.get(f"{BASE}/profile",
            params={"name": title, "company": company},
            headers={"Authorization": f"Bearer {API_KEY}"})
        data = r.json()
        if data.get("linkedin_url"):
            return data
    return None

def enrich_email(linkedin_url):
    r = requests.get(f"{BASE}/email",
        params={"linkedin_url": linkedin_url},
        headers={"Authorization": f"Bearer {API_KEY}"})
    return r.json().get("email")

with open("targets.csv") as f, open("enriched.csv", "w") as out:
    writer = csv.writer(out)
    for row in csv.DictReader(f):
        person = find_decision_maker(row["company"])
        if person:
            email = enrich_email(person["linkedin_url"])
            writer.writerow([row["company"], person["name"],
                             person["linkedin_url"], email])

Run time for 200 companies: roughly 8-12 minutes. Credit cost on a typical B2B enrichment API: ~200 profile lookups (300-400 credits) + ~150 email lookups at a 60-75% hit rate (750-1500 credits). Total: ~1,000-2,000 credits, well inside a $20/month entry tier.

The same workflow on an unofficial scraping API would cost roughly $5-15 in per-call fees and carry the LinkedIn ToS exposure. The same workflow on official LinkedIn APIs is not possible at all because cold profile search is not part of any partner program.

Chapter 5: Picking between the three

A short decision tree based on the team profile.

Pick an official LinkedIn API if: you are building an integration LinkedIn would happily endorse - an ATS bidirectional with LinkedIn Recruiter, an ad-tech platform tied to Marketing Developer Platform, a CRM with Sales Navigator partner status. Plan for the partner application process and an enterprise contract.

Pick an unofficial scraping API if: the data you need only exists inside LinkedIn's social graph (recommendations, connection lists, recent activity feed) and you have legal counsel comfortable with the LinkedIn ToS exposure. Reserve this for research, journalism, due-diligence workflows. It is not a fit for a daily SDR pipeline because the reliability and the legal posture both sit on the wrong side of the line.

Pick a B2B enrichment API if: you are running a normal prospecting or recruiting workflow that needs LinkedIn URLs, names, headlines, current company, role, location, email, and phone for cold contacts. This is the workhorse for the 90%+ of teams that talk about "needing a LinkedIn API". The data is LinkedIn-shaped without being LinkedIn-sourced.

For team workflows that already use a Chrome extension on LinkedIn pages, the Chrome extension comparison covers the same vendors from the in-tab side. For workflows where the AI assistant is the operator instead of code, the LinkedIn scraper MCP guide covers the MCP-shaped version of the same surface. The credits, in most cases, are shared across all three entry points (extension, API, MCP) when the vendor offers all three.

Which route fits your workflow

Answer two questions and the category picks itself. The estimator below applies the same logic as the table, including the approval reality check that most comparison posts leave out.

LinkedIn API access: what you get by default, what needs a partner program

LinkedIn API access splits cleanly in two, and knowing which half you are in saves weeks. By default, with no application and no review, you get authentication and publishing on behalf of the member who signs in. Everything that reads or writes data belonging to somebody else sits behind a programme.

The question that brings most developers here is some version of the one a founder asked on a public forum this year: my product needs to read profiles, how do I get access. The honest answer has three parts.

• By default you get sign-in, the signed-in member's own profile and email, and the ability to post as that member. Minutes to set up, no review.
• A partner programme gets you ads data, Page management, recruiting workflows, Sales Navigator sync, learning records or compliance archives, depending on the programme. Weeks to months, and the review is commercial rather than technical.
• Nothing gets you cold profile lookup. It is not a tier you can buy. If reading arbitrary profiles is the product, the official API is not the route, and pretending otherwise is how teams lose a quarter.

For that third case there is a route neither LinkedIn nor the scraping vendors describe, and it is the one most prospecting teams end up on: a B2B enrichment API that sources its own data and answers on a profile or company URL without any LinkedIn partnership at all. Chapter 4 covers what it returns and what it costs.

Applying to a partner program, and how long approval really takes

There are two doors, and they behave completely differently.

The self-serve door. You sign in to the developer portal with a real LinkedIn account, create an app, and attach a company Page you administer. LinkedIn verifies the link by asking a Page admin to confirm. Once verified, the self-serve products (sign-in, sharing, plugins) are available immediately. Using a fake account here breaks the terms of service and is the fastest way to lose the app entirely.

The programme door. The five gated families are Marketing Developer Platform, Community Management, Talent Solutions, the Sales Navigator Application Platform and Learning, with Compliance sitting alongside them behind an eligibility check rather than a commercial review. None of them is switched on by a button. You apply to the specific programme, and the application is a business review rather than a technical one. LinkedIn wants to see a real product, a real customer base, and a use case that adds something to their ecosystem instead of extracting from it.

Plan for the timeline honestly:

• Initial review of a complete application: roughly two to four weeks.
• Each round of follow-up questions: another one to two weeks.
• Realistic end to end, application to production credentials: four to twelve weeks.
• After a rejection, most programmes expect you to wait six to twelve months before reapplying, and to have materially changed something in between.

The applications that get declined usually share a shape: a pre-revenue product with no users, a use case that boils down to exporting member data, or an integration that duplicates something LinkedIn already sells. If your plan is to build a prospecting list, the programme door is not slow, it is closed. That is the honest answer, and it is why the rest of this guide spends its time on the other two categories.

LinkedIn API rate limits, throttling, and the 429 response

Teams that do get approved are often surprised by the second wall: throttling. The LinkedIn API applies quotas on two separate planes at once, and you can breach either one.

• Application-level quota: the total number of calls your app can make to a given endpoint in a day, across every user.
• Member-level quota: the number of calls your app can make on behalf of one authenticated member in a day.

Both counters reset at midnight UTC, not at a rolling 24-hour mark from your first call. A batch job scheduled at 23:00 UTC therefore gets an hour of quota, not a day of it. When you exceed either plane the API answers with HTTP 429, and the response does not tell you which plane you hit. That ambiguity is the part that costs engineering time.

Four things keep an integration inside the limits:

1. Exponential backoff on 429, with jitter. Retrying immediately burns the rest of your quota against errors.
2. Field projections. Ask only for the fields you use. Fat responses do not cost more calls, but they make caching and diffing more expensive downstream.
3. Batch endpoints where they exist, instead of looping single lookups.
4. A cache with an explicit freshness policy. Re-reading data that has not changed is the most common way teams burn a daily quota by lunchtime.

Enrichment APIs fail differently, and it is worth naming the contrast. They meter credits, not calls per day. Running out means an invoice conversation, not a blocked integration at 11am with a queue backing up. For a prospecting workload, where volume is bursty and deadlines are campaign-shaped, that difference matters more than the headline unit price.

Authentication and versioning: what breaks a LinkedIn API integration

Two mechanics account for most of the silent breakages people report months after going live.

OAuth 2.0, in two flavours. Three-legged OAuth is the member-authorised flow: the member clicks through a consent screen and your app receives a token scoped to what that member allowed. Two-legged OAuth is app-only, used for a narrow set of programme endpoints where no member context exists. Scopes are not something you request freely, they are attached to the products your app has been granted. Asking for a scope your app does not hold returns an authorisation error that reads like a bug and is actually a permissions decision.

Member access tokens expire. Refresh tokens are available to approved programmes but not to every self-serve app, which means some integrations genuinely require the member to re-authorise on a schedule. An integration that worked perfectly for two months and then went quiet is almost always an expired token that nobody was alerting on.

The refresh trap is the line that matters. A self-serve app without refresh tokens needs the member to re-authorise on a schedule, and nothing in the platform reminds you of that. If nobody alerts on token age, the first symptom is a sales team asking why a sync stopped six weeks ago.

Versioning. Modern LinkedIn endpoints are versioned through a request header carrying a year-month value, and versions age out on a published schedule. Pinning a version is correct engineering, but pinning it and never revisiting it means your integration has an expiry date you did not write down. A minimal request looks like this:

curl -X GET 'https://api.linkedin.com/rest/me' \
  -H 'Authorization: Bearer {access_token}' \
  -H 'LinkedIn-Version: 202601' \
  -H 'X-Restli-Protocol-Version: 2.0.0'

Three headers, and two of them are the ones people forget. Drop the version header and you get an error that says nothing useful about the cause.

The operational lesson generalises beyond LinkedIn: any integration built on a partner-gated API inherits that partner's release calendar. Budget maintenance for it, or choose a category where you do not have to.

Key takeaways

• Three categories of LinkedIn data extraction API exist in 2026: official LinkedIn APIs (compliant, narrow), unofficial scraping APIs (broad, ToS-violating), B2B enrichment APIs (broad, compliant, vendor-sourced).
• Official LinkedIn APIs do not cover cold profile lookup. They serve ad tech, ATS, CRM partners.
• Unofficial scraping APIs cover the broadest surface but transit a Section 8.2 violation that the buyer inherits as a data controller.
• B2B enrichment APIs cover the prospecting and recruiting workflow at $20-100/month entry tiers with no LinkedIn ToS exposure.
• Same vendor often exposes the API, the Chrome extension, and the MCP endpoint from a shared credit pool.