Can I Use These Scraping Services for LinkedIn Data?

We get this question several times a week, usually phrased as a yes/no. It is not a yes/no. There are two different activities here with different legal analyses, different technical difficulty, and different answers from us.

This is not legal advice. It is a description of where our policy line sits and why.

Two activities, not one

Publicly visible profile data — what a logged-out visitor sees at a public profile URL, including name, headline, current employer, and public post text.

Logged-in data — anything behind authentication: connection lists, full employment history on restricted profiles, InMail, group membership, Sales Navigator result sets, or search beyond the logged-out limits.

Every meaningful distinction follows from which of these you mean.

What hiQ actually decided

The case is cited constantly and usually wrongly.

The Ninth Circuit held that scraping publicly available data likely does not violate the CFAA, because data open to the general public is not "without authorization" in the statutory sense. That was a real and durable win for public-web collection.

Then, in 2022, hiQ lost on the other claim: it had breached LinkedIn's User Agreement, having accepted those terms and having used fake accounts and third-party scrapers. The case settled with hiQ under a permanent injunction and effectively out of business.

The correct summary is: scraping public data was not a computer-crime problem; doing it through accounts that had agreed not to was a contract problem, and the contract problem was fatal. Anyone quoting hiQ as blanket permission has read half of it.

Add to that:

• LinkedIn's User Agreement prohibits automated access, scrapers, bots, and the use of software to extract data. Creating an account binds you to it.
• The EU regards profile data as personal data. There is no "it was public" exemption under GDPR; there is a lawful-basis analysis, and legitimate interests must survive a balancing test against the data subject's reasonable expectations. The Dutch and French authorities have taken active positions here.
• Creating accounts with false identities to enable collection is itself a terms breach and, depending on jurisdiction and use, potentially more than that.

What FleetProxy permits

Permitted. Accessing publicly available pages as a logged-out visitor, at a rate that does not degrade the service, where the data class is lawful for you to process and you have addressed your own data-protection obligations.

Prohibited under our Acceptable Use Policy. Authenticating with credentials you are not authorised to use. Operating accounts created under false identity for collection. Credential stuffing or any form of access-control circumvention. Bulk harvesting of personal data with no lawful basis. Continuing to collect from any operator that has served you a specific notice to stop.

Those are not aspirational. A report with evidence triggers the enforcement process in the AUP, which starts with a request for explanation and ends, where warranted, with suspension.

Lawful alternatives that actually work

Most requests we see have a business goal that a compliant route serves better.

The recurring pattern: the licensed route costs money and removes an entire category of risk, and teams usually discover the numbers are close once they price the engineering time that automated collection actually consumes.

If you are collecting public data lawfully

Assume you have done the analysis and concluded a specific, narrow collection is lawful for you. Technically it is still one of the harder public targets.

Expect strong bot management: TLS fingerprinting, aggressive rate limits on logged-out browsing, quick escalation to challenges, and an authentication wall that appears after a small number of profile views from one address. Datacenter address space is filtered heavily.

# Residential exit, session held for one journey, single-digit requests per minute
curl -x http://user-country-us-session-4c1de907ab52:[email protected]:8080 \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36" \
  -H "Accept-Language: en-US,en;q=0.9" \
  -sS -o /dev/null -w "%{http_code}\n" https://example.com/public-page

Three engineering rules if you proceed:

1. Store the minimum. Fields you need, nothing else. Every extra personal-data field is retention scope, subject-access scope, and breach scope you chose to take on.
2. Honour deletion. If a profile disappears or a subject objects, your copy must go too. Build that path before the collection path.
3. Log lawful basis per record. When a regulator or a subject asks why you hold something, "we scraped it" is not an answer.

The honest summary

Public data collection at modest scale, with a real lawful basis, done as a logged-out visitor, is something we support and will not block. Anything requiring an account, a fake identity, or the circumvention of an access control is something we prohibit and will act on. If a proposed project can only work by crossing that line, the project needs a different design, not a different proxy provider.