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.

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.

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.

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.

How to get LinkedIn API access, and how long approval 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. Marketing, Talent, Sales and Compliance products are not 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.

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.

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.

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.

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.