"LinkedIn API" or "LinkedIn data API" usually means LinkedIn's partner and Marketing Developer Platform products. In practice, teams shopping those phrases need one of three things: member-authorized apps LinkedIn has approved, public person or company enrichment without a partner deal, or browser automations that scrape Sales Navigator-shaped workflows.

Those are different products. Mixing them up is how you end up buying Phantom hours when you needed a profile GET, or waiting months for partner access when a public-page lookup would have shipped the feature. Longer walkthrough of that fork: LinkedIn partner API vs public data.

Proxycurl shut down in July 2025 after LinkedIn litigation. Rate cards from a dead vendor still float around in RFPs. Treat those numbers as history, not a February 2026 budget. Re-check each vendor's pricing page before you commit.

Social Fetch is my pick for sync REST over public LinkedIn people, companies, posts, jobs, Ad Library, and search, especially if you already normalize creators across TikTok and Instagram. Use LinkedIn's official APIs when you need member OAuth or partner features. Use Enrich Layer for the lowest-effort migration off Proxycurl when LinkedIn is your only network. Use Apify for custom Actors or scheduled batch dumps. Use PhantomBuster for outreach automation, not JSON for your backend.

The short list

1. Social Fetch — sync REST for public LinkedIn data, same envelope as other platforms
2. LinkedIn official APIs (partner / MDP) — authorized route for member scopes and LinkedIn-approved products
3. Enrich Layer — LinkedIn-focused successor path after Proxycurl shut down
4. Apify LinkedIn Actors — marketplace scrapers when you need custom fields or scheduled runs
5. Bright Data / Oxylabs — enterprise proxy and dataset infrastructure at volume
6. PhantomBuster — cloud automation for sales playbooks, not a profile schema API
7. RapidAPI LinkedIn listings — discovery marketplace, not one production contract

Full LinkedIn route list and examples live on the LinkedIn platform page. Partner vs public enrichment decision: LinkedIn partner API vs public data.

How I rank LinkedIn data APIs

I care about production behavior, not landing-page adjectives:

1. What you can actually call — people profiles, companies, organizations/schools, posts, people search, jobs, Ad Library, transcripts. Count real paths, not "LinkedIn support" on a marketing grid.
2. Official vs public enrichment — member-authorized partner APIs are a different compliance and product path from public-page JSON. Know which one your counsel and product actually need.
3. Sync vs async — one HTTP response you can await in a product request, or start-a-run / poll-a-dataset / burn execution hours.
4. Person vs company vs job — /in/…, /company/…, and job URLs are different entities. Vendors that collapse them into one "LinkedIn scrape" endpoint force your code to guess.
5. Error shape — typed lookupStatus and a requestId beat silent empty HTML or a 200 with a broken parser.
6. Multi-platform tax — if your app already pulls TikTok and Instagram, does LinkedIn force a second schema and a second vendor?
7. Vendor concentration risk — Proxycurl proved a LinkedIn-only enrichment business can vanish. Ask what happens if this network gets harder, not only what the demo returns today.
8. Compliance fit — official API for experiences LinkedIn approves; third-party public-data APIs for enrichment of publicly visible pages. Read LinkedIn's Terms for your use case. I am not your lawyer.

Ranked picks

1. Social Fetch — public LinkedIn over one REST key

Good fit for product teams and agents that need public person cards, company pages, posts, jobs, and search without a LinkedIn partner app, and that already (or soon will) pull other social platforms.

Social Fetch exposes first-party LinkedIn routes under /v1/linkedin/*: person profiles (batch up to 50 URLs), profile posts, people search, organizations, company pages, company posts, individual posts, post transcripts, post search, Ad Library get/search, jobs, and job search. Thirteen documented operations as of February 2026. Responses use the shared { data, meta } envelope. Follower-style metrics land in the same conventions as other platforms, so cross-network account scores do not fork on field names.

Sync GET routes cover the common enrichment path. No Actor run polling for profile or company cards. Person, company, and organization routes are separate. You do not feed a /company/… URL into a person endpoint and hope. Batch profile lookups accept up to 50 URLs per request at 2 credits per URL requested. Every response includes meta.requestId and meta.creditsCharged. The same API key works for TikTok, Instagram, YouTube, and the rest of the catalog. Signup includes 100 free credits with no card; PAYG packs do not expire.

Watch the scope: this is public enrichment, not Sales Navigator, InMail, or LinkedIn partner analytics. People search and job search are slower and metered differently than a single profile GET. Plan for about a minute and a half on those searches, and read the credit blurb (attempt fee plus per-record credits). Heavier routes cost more than a simple company GET. Coverage follows what is publicly visible. Gated or logged-in-only sections are out of scope.

Credits charge on completed lookups. Trust meta.creditsCharged on every response, not a spreadsheet guess. Profile GETs are 2 credits per URL requested. Company pages, posts, and many other flat routes are 1 credit on success. People search bills a 2-credit attempt fee plus 2 credits per person returned. Free tier (100 credits) → Starter $14 (1,000) → higher packs on pricing.

My default pick when LinkedIn is one surface in a multi-platform product, or when you want sync public JSON without waiting on partner access.

For a one-off paste-and-copy person lookup without wiring keys, use the free LinkedIn profile viewer. Full route list: LinkedIn hub.

2. LinkedIn official APIs — when you need LinkedIn's auth model

Good fit for apps that manage member-authorized experiences, Marketing Developer Platform features, or must stay inside LinkedIn's partner access model.

LinkedIn's official APIs are the correct product when LinkedIn has to approve what you build. Partner and MDP processes gate access. That is the right path for products that act as a LinkedIn-connected app, not for "look up any public /in/… card for CRM enrichment" research jobs.

First-party ToS path when you qualify. Stable docs for the surfaces you are allowed to call. Fine for member OAuth flows you already run. Access is not "sign up and GET any profile." Many enrichment use cases never get the scopes teams assume exist after watching a general "LinkedIn API" tutorial. Expect review timelines.

Use it when ownership and compliance require LinkedIn partner access. Supplement or replace it for public enrichment volume if you never get (or should not apply for) those scopes.

3. Enrich Layer — LinkedIn-only continuity after Proxycurl

Good fit for teams that need the lowest-effort migration off Proxycurl and whose roadmap is LinkedIn enrichment only.

Proxycurl shut down in July 2025 after LinkedIn litigation. Enrich Layer positions itself for former customers: similar endpoints, key/credit carryover for many users, base URL change. If wire compatibility beats multi-platform breadth, evaluate that path first.

Explicit migration story. LinkedIn-deep focus. Less remap work if your clients already speak Proxycurl-shaped requests. You are still concentrating enrichment risk on one network and one operator lineage. Field depth and people-search behavior are not identical to Social Fetch. Compare against your actual payloads, not nostalgia for old Proxycurl rate cards.

Right for LinkedIn-only stacks that refuse a schema remap. Wrong as your only integration if TikTok or Instagram is next quarter. Longer migration notes: Social Fetch vs Proxycurl.

4. Apify — LinkedIn Actors for custom and batch work

Good fit for scheduled profile dumps, niche field extraction, and scrapers you want to configure as Actors rather than maintain as a fleet of browsers.

Apify hosts many LinkedIn Actors (profile, company, posts, jobs, sales-adjacent scrapers). You start a run, poll, download a dataset. Schemas differ by Actor author. Billing mixes compute and event fees; monthly plan credits expire.

Marketplace breadth. Good when no managed REST route exposes the field you need. Scheduling is built into the platform. You are buying a runtime, not one LinkedIn schema. Actor quality varies. Sync product UIs that need a single HTTP round trip fit poorly. LinkedIn anti-bot pressure hits Actor authors unevenly.

Right for batch and custom scrapes. Wrong as your only integration if you want one typed client for person + company in a request handler.

5. Bright Data and Oxylabs — enterprise infrastructure

Good fit for high-volume teams with budget for proxy networks, dataset pipelines, and sales-led contracts. Overkill for a product engineer who only needs public /in/… JSON in an onboarding flow.

These vendors sell unblock and collection infrastructure. LinkedIn scrapers and dataset products exist on top of residential IPs, browser farms, and async exports. You are buying a platform with spending limits, domain tiers, and procurement cycles that large data orgs already understand.

Social scraper list prices commonly land in a rough ~$2.50–$3.70 per 1,000 records band depending on product page and commitment (verify current Bright Data / Oxylabs quotes before you budget). Floors and spending caps matter as much as the unit rate: hit a cap on launch day and requests stop until someone with admin access raises the limit.

Hard-target reliability when volume justifies the stack. SLAs and legal processes enterprises already staff for. Warehouse delivery patterns that sync REST does not try to replace. No unified multi-social schema by default. You still own parsers unless you buy a higher-level dataset product.

Justified when volume and hard-target success rates dominate the spreadsheet. Wrong shape for a startup shipping CRM enrichment on public pages. See Social Fetch vs Bright Data.

6. PhantomBuster — automation studio, not a data API

Good fit for growth and sales ops that need cloud browser playbooks (scrapes into Sheets, outreach sequences), billed in execution hours and slots.

PhantomBuster is easy to put on "LinkedIn API" lists because LinkedIn Phantoms are popular. The product is automation runtime. Paid plans expose an API to drive those automations. You still think in hours, slots, and exports, not one credit per typed profile response.

Pre-built sales workflows. Fine when a human or ops tool owns the pipeline. Awkward inside a SaaS request handler that needs 500 profile cards during onboarding. Export caps on free/trial tiers. Wrong abstraction if you only wanted JSON.

Keep it for outreach playbooks. Do not use it as your production LinkedIn enrichment API. Longer take: Social Fetch vs PhantomBuster.

7. RapidAPI LinkedIn listings — browse, then graduate

Good fit for finding a niche LinkedIn endpoint over a weekend without signing an enterprise contract or a partner deal.

RapidAPI hosts third-party LinkedIn scrapers under one billing dashboard. Discovery is the product strength: pick a listing, hit the test console, see whether the JSON looks like a person card or a half-parsed HTML dump. Prototypes move fast because you are not waiting on Marketing Developer Platform review.

LinkedIn is a hard target. Listing quality varies more than on softer networks, and anti-bot pressure hits publishers unevenly. Production teams that stitch three LinkedIn marketplace APIs usually inherit three schemas, three rate limits, and three places a publisher can vanish after a ToS scare. Multi-platform enrichment (LinkedIn plus Instagram plus TikTok) multiplies that into separate subscriptions. Marketplace scrapers often price in the rough $2.50–$4+ per 1,000 range per listing. Treat that as a starting guess and verify the publisher before you promise CRM volume.

Fast shopping. Low commitment for a one-weekend experiment. Fine if LinkedIn is a tiny input among many unrelated RapidAPI line items. Person vs company vs job endpoints may be separate listings with incompatible shapes. Support tickets route through a middleman. Proxycurl-style shutdown risk exists for any single LinkedIn-only publisher sitting on a marketplace shelf.

Keep it for exploration. Prefer a first-party public-data API (or Enrich Layer for LinkedIn-only Proxycurl continuity) when enrichment is load-bearing. Longer take: Social Fetch vs RapidAPI.

Official API vs public enrichment

Most "LinkedIn API" comparisons bury this fork. In 2026 it decides the vendor list before pricing does. If you want the access-friction version of the same decision, read LinkedIn partner API vs public data. For DIY vs partner/MDP vs Social Fetch with runnable GETs, see How to scrape LinkedIn data.

Social Fetch only returns publicly visible data. Content gated beyond public visibility is out of scope. Official APIs do not magically unlock "any profile on the internet" either. They unlock what LinkedIn authorizes for your app and members.

Edge cases on our side: pass a company URL into the person profile route and you will not get a company card. Use GET /v1/linkedin/companies or GET /v1/linkedin/organizations for the right page type. Branch on lookupStatus before you upsert.

Which API fits which job

• Multi-platform enrichment product, sync JSON → Social Fetch (LinkedIn hub)
• LinkedIn partner / member-authorized app → Official LinkedIn APIs
• Proxycurl-shaped LinkedIn-only migration → Enrich Layer first; Social Fetch if you are rebuilding anyway
• Nightly scrape with custom fields → Apify Actor
• Enterprise proxy volume → Bright Data or Oxylabs
• Outreach automation playbooks → PhantomBuster
• One-off person profile in the browser → /tools/linkedin-profile-viewer

If you only need LinkedIn today but Instagram next quarter, pick the option whose envelope you can reuse. Rewriting parsers per platform is where most "cheap" LinkedIn APIs get expensive.

Questions before you buy

1. Do you need member-authorized scopes, or public enrichment? That fork decides official vs third-party first.
2. Person, company, job, or Ad Library? Confirm the vendor has separate, documented paths, not one HTML dump.
3. Will people/job search latency fit your UI? Some search routes take well over a minute. Product handlers that need sub-second cards should not share a path with deep search.
4. Sync or batch? Product request handlers prefer sync. Overnight dumps can live on Actors or datasets.
5. One schema across platforms? Call LinkedIn and TikTok with the same parser. If you need if (platform === "linkedin") for basic identity fields, you do not have unification.
6. Do credits expire? Spiky enrichment workloads hate monthly resets.
7. What is your single-vendor LinkedIn risk? Ask what you do if this provider disappears the way Proxycurl did.
8. Can you preview without shipping? Use a playground, free credits, or the free LinkedIn profile viewer before you lock a vendor.

Frequently asked questions

What is the best LinkedIn Data API in 2026?

For public sync REST with people, companies, posts, jobs, Ad Library, and search, and the same envelope as other social platforms, Social Fetch is my pick. I built it. LinkedIn's official APIs win for partner and member-authorized work. Enrich Layer wins for lowest-effort Proxycurl migration when LinkedIn is the only network. Apify wins for custom Actors. PhantomBuster wins for sales automations.

Is there an official free LinkedIn API for any public profile?

LinkedIn's developer products are built around authorized apps and approved use cases, not an open "GET any /in/… URL" enrichment free-for-all. For public-page enrichment without partner access, teams use third-party public-data APIs. Read LinkedIn's Terms and talk to counsel for your jurisdiction.

Can I get LinkedIn company pages via API?

Yes on Social Fetch: GET /v1/linkedin/companies with a public company URL (1 credit on a completed lookup). Schools and other organization page types use GET /v1/linkedin/organizations (2 credits per URL requested). Details: /platforms/linkedin.

LinkedIn scraper API vs LinkedIn official API — which should I use?

Use the official API when you need LinkedIn's auth model and partner features. Use a managed public-data API when you need enrichment of publicly visible pages without Marketing Developer Platform access. Scrapers and Actors fill gaps neither covers; they also shift maintenance and compliance risk onto you. Step-by-step DIY vs partner/MDP vs Social Fetch, including metered people search: How to scrape LinkedIn data.

What happened to Proxycurl?

Proxycurl shut down in July 2025 after LinkedIn litigation. Enrich Layer is the common continuity bet for LinkedIn-only stacks. Social Fetch is a separate multi-platform rebuild option. See Social Fetch vs Proxycurl.

Does Social Fetch require a LinkedIn partner app?

No. You need a Social Fetch API key. We return publicly visible LinkedIn data for enrichment-style lookups. Route list: /platforms/linkedin.

Smoke-test a person or company URL in the playground, or start with 100 free credits on pricing. For one public person profile without an API key, open the free LinkedIn profile viewer. Partner vs enrichment path: LinkedIn partner API vs public data.