LinkedIn Scraping vs a Safe API: What to Use in 2026

Scraping LinkedIn means running a bot over pages your code does not own. It breaks whenever LinkedIn changes its markup, and it breaches the User Agreement every account on your team agreed to. An account-based LinkedIn API returns the same profile, company and search records through a typed contract, on an account you connect yourself, inside limits a server enforces.

Which route you want depends less on the data and more on how long the thing has to keep working. Across 20,000+ LinkedIn accounts, gtm-api.com reports under a 1% ban rate on the account-based route, and the scraping route spent 2025 losing its best-known vendor to a lawsuit.

What counts as LinkedIn scraping

LinkedIn scraping is any automated read of LinkedIn pages through an interface LinkedIn did not open to you. The bot loads the same HTML a browser loads, pulls fields out of it, and stores them. Nothing about that is exotic. What makes it a category of its own is that the parsing target is a product surface, so it changes on LinkedIn’s release schedule and never on yours.

Three shapes of it turn up in real stacks, and they carry very different risk.

• Logged-out crawlers. A bot fetches public profile URLs with no session. This is the shape the hiQ litigation was about, and the one with the strongest legal argument behind it. It also returns the least, because LinkedIn shows a signed-out visitor a trimmed profile and an authentication wall a few pages in.
• Logged-in session scripts. A cookie or a headless browser drives a real member account through the normal UI and reads the internal JSON the front end calls. This returns almost everything a member can see. It is also the shape that gets accounts restricted, because every request carries the account’s identity.
• Resold datasets. A vendor scraped at scale earlier and sells you the stored copy. You never touch LinkedIn, so nothing of yours is exposed, and the record is exactly as fresh as the last crawl. LinkedIn profile data API covers what those providers can legally hand you and how long you may keep it.

What an account-based API is

An account-based LinkedIn API is a managed service that acts through a real LinkedIn account you connect, and returns the records that account can see as typed objects, so your code reads structured fields instead of parsing HTML off the page. It sits next to the logged-in scraper above and runs the opposite way: the account is one you own and authorise through a consent flow, the session is isolated to it, and the platform holds the send and read budgets in front of every call before it reaches LinkedIn.

Four properties separate it from a scraper driving a member account.

• A connected account. You link the account yourself and can revoke it, so nothing rests on a borrowed cookie or a credential living inside a script.
• A typed contract. Endpoints return documented fields, so a LinkedIn redesign leaves the data intact where a moved selector would quietly empty it.
• Server-side budgets. Per-action limits and pacing are enforced on the platform, so the account stays under its ceiling instead of finding it by hitting it, the difference that shows up in what gets accounts restricted.
• An isolated session. Each account runs in its own cloud browser on a dedicated proxy, so one fingerprint never serves a fleet.

Scraper or API: which one fits the job

Use a scraper for a one-off pull you can throw away, on an account you can afford to lose. Use an account-based API for anything that has to run next quarter, anything that writes back to LinkedIn, and anything a customer sees. The table sets the account-based route against the three scraping shapes, which read similar fields and fail in completely different ways.

The column that decides most builds is the fourth one. A scraper reads. Outreach needs a write path, and writing is where LinkedIn’s enforcement lives, so a stack that scrapes for data and then sends through some other tool has put the risky half of the job in the place with the least control over it. Best LinkedIn API ranks the vendors on that axis, scraper APIs included.

Is scraping LinkedIn legal?

There is no single answer, because two separate questions get asked at once. Is it a computer crime, and is it a breach of contract. United States courts have now answered both in the same case, and they answered them differently. Scraping public pages is probably not a crime. Doing it after agreeing to LinkedIn’s User Agreement is still a breach of that agreement.

Data protection is a third question again, and it is the one where the fines have landed. A scraped profile is personal data about a named person, so storing it, enriching it and mailing it are all processing under the GDPR, and France’s regulator fined a LinkedIn contact scraper EUR 240,000 in December 2024 on exactly that ground. How each of the three questions was decided, the consent judgment that ended hiQ’s scraping for good, and which of them reaches an ordinary B2B team are on Is scraping LinkedIn legal?. The storage terms LinkedIn itself imposes on its API partners are on LinkedIn profile data API.

Automation through a connected account is a grey area of its own, covered on LinkedIn API: the developer guide.

Why scraping is what gets accounts restricted

LinkedIn does not need to identify your parser to stop you. It watches how the account behaves, and a scraper behaves in a way a member never does: hundreds of profile views in an hour, a request cadence with no human pauses in it, a traversal order that walks a list from top to bottom, and a session that keeps going after the first refusal. Any one of those is survivable. Together they are a signature.

Four things separate an account that reads a lot from an account that gets stopped.

• Volume with no budget in front of it. A scraper has no idea what the account’s ceiling is, so it discovers the ceiling by hitting it. LinkedIn’s per-action caps and their reset clocks are on LinkedIn limits.
• A fixed cadence. One request every two seconds forever is a machine, and the regularity itself is the tell. Randomised intervals cost throughput and buy the account time.
• A shared fingerprint or a shared IP. Two accounts on one browser profile or one datacentre address read as one operator running both, and the association survives a cookie reset.
• Retrying into a refusal. When LinkedIn declines an action, a retry loop turns one refused request into a pattern of them. The recovery window is per action type and it is measured in hours.

The enforcement ladder that follows is documented on LinkedIn account restricted: throttling first, then a checkpoint, then a temporary restriction, then a permanent one. Recovery gets harder at every step, and a permanently closed account takes its connection graph and its message history with it. That is the real cost of the free route, and it lands on the account of whoever ran the script.

The same data through an account-based API

On the account-based route, each record is one authenticated call. Your code calls typed endpoints that return parsed objects, and the fields are the ones the connected account can see on LinkedIn, so a first-degree connection returns contact details and a stranger does not.

curl -X POST https://app.gtm-api.com/linkedin/v4/api/linkedin-enrichment/person-full-profile \
  -H "Authorization: Bearer $GTM_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"public_identifier": "https://www.linkedin.com/in/...", "linkedin_account_sid": "ln_ac_..."}'

The read side covers person and company profiles, the field groups under them (experience, education, skills, certifications, recommendations, contact info), people and company search, Sales Navigator search, and the reactors and commenters on a post. The write side covers connection requests, messages, InMail and engagement, on the same contract and behind the same budgets. Every field-level question about profiles is answered on LinkedIn profile data API, and the endpoint reference is in the developer docs.

Two things about this route are worth being straight about. It costs money where a script costs your time, and it can only ever return what the connected account is allowed to see, so it will never match a bulk dataset for raw coverage. What you get for that is a record fetched at request time, a send path on the same credential, and a limit engine that stops the account before LinkedIn does. The safety stack itself is on Safe LinkedIn automation, and the agent-side contract is on LinkedIn MCP server.

What each route costs to keep running

The build cost of a scraper is a weekend. The running cost is the part that gets underestimated, and it arrives as three separate bills: engineering time on breakage, infrastructure to stay unblocked, and replacement accounts.

Breakage is the predictable one. Selectors and internal JSON shapes move when LinkedIn ships, and nobody warns you, so the failure surfaces as empty fields in your database days later. Staying unblocked means a proxy pool, fingerprint rotation and challenge handling, all of which are somebody’s ongoing job. Replacement accounts are the quiet line item, because a restricted account takes its warm-up history with it and a fresh one starts at a fraction of the sending capacity, which Scaling LinkedIn outreach puts numbers on.

Vendor risk belongs in the same column. Proxycurl was the best-known LinkedIn profile API of its generation. LinkedIn sued its operator in January 2025, and on 4 July 2025 the founder announced the shutdown in a post that cited the cost of defending the case. The case details and what the shutdown changed for the dataset market are on LinkedIn profile data API. Anything built on a single scraping vendor inherits that vendor’s legal position.

Priced per unit, the two routes look closer than they are. Scraper APIs and datasets bill per result or per credit, so the bill grows with every lookup and every re-check of a record you already have. Account-based pricing is per connected account, from $10 per account per month at volume on GTM API pricing, with the calls unmetered, so the cost is set by how many identities you operate. Volume enrichment across millions of records still favours a dataset. A workflow that reads a profile and then acts on it favours the account.

So which is better, scraping or an API?

Everything above, on one screen. The eight rows are the ones that decide a build, and the honest read is that each route wins where its design points it.

So it comes down to the goal, and for most goals the account-based route takes it. Scraping wins one thing outright, raw volume: nothing working through a single connected account will match a dataset for millions of records. On reliability, the terms line, ban risk, freshness and the write path outreach needs, the API is ahead, and those are the rows that decide whether a build survives the quarter. Reach for scraping when sheer volume is the whole job. For anything that has to keep running, use the API.

Frequently Asked Questions

Read next on this topic

• Is scraping LinkedIn legal?
• LinkedIn job scraper
• LinkedIn email scraper

Sources & Further Reading

• United States Court of Appeals for the Ninth Circuit, hiQ Labs, Inc. v. LinkedIn Corp., No. 17-16783, opinion filed 18 April 2022 (the CFAA holding on public profiles)
• Proskauer, New Media and Technology Law Blog, analysis of the district court ruling of 4 November 2022 (the breach-of-contract holding)
• Nubela, Goodbye Proxycurl, 4 July 2025 (the founder’s own shutdown announcement)
• gtm-api.com, developer documentation (the enrichment and search endpoints named above)
• Related: LinkedIn profile data API · LinkedIn API: the developer guide · Best LinkedIn API · Safe LinkedIn automation · LinkedIn account restricted · LinkedIn posts API · Is scraping LinkedIn legal? · Proxycurl overview

Michael SalamatovGTM engineerRuns the gtm-api.com blog. Covers LinkedIn limits, account health and the API side of outbound.in

Last updated: September 2026 · Court records, the Proxycurl announcement and the endpoint paths verified against primary sources on 20 August 2026