Is LinkedIn Scraping Legal? What hiQ and the Proxycurl Case Actually Established

This is not legal advice. It is a summary of publicly reported cases written by engineers, not lawyers, and the position varies by jurisdiction and by what you do with the data. Take your own advice before building a business on any of it.

What hiQ v LinkedIn actually decided

hiQ Labs scraped public LinkedIn profiles to sell attrition predictions. LinkedIn sent a cease and desist; hiQ sued. The case ran for years and is the one everybody cites.

The narrow holding that survived: scraping data that is publicly accessible without authentication does not violate the US Computer Fraud and Abuse Act, because there is no "access without authorisation" when no authorisation was required.

That is genuinely significant. It is also much narrower than the headlines suggested. It said nothing about copyright, nothing about breach of contract, and nothing about data protection. The case did not end with hiQ vindicated — it later turned on LinkedIn's contract claims, and hiQ's position deteriorated considerably.

The lesson most people took from hiQ was "public scraping is legal". The lesson the record supports is "public scraping is not a computer intrusion crime, and that is only one of several ways to be liable".

What the Proxycurl shutdown demonstrated

Proxycurl was a well-regarded LinkedIn data API with a real developer following. LinkedIn brought legal action against its operator, and in 2025 the service announced it was shutting down.

Whatever the legal merits, the practical demonstration is what matters if you are choosing a vendor: a provider in this category can disappear, and your integration goes with it. That is a vendor-risk question as much as a legal one, and it applies to every provider here — us included. Anyone claiming structural immunity is selling confidence they do not have.

The terms of service question

LinkedIn's user agreement prohibits automated scraping. Whether that binds you depends on whether you agreed to it — which generally means whether you have an account and are logged in.

This is the sharpest practical distinction in the whole area. A tool using your cookies operates as a logged-in user who accepted those terms. A server-side fetch of a public page by a party with no account is in a materially different position. It is also why the cookie-based approach carries account risk that the API approach does not: you agreed to something, and automation is what you agreed not to do.

The GDPR is the part people skip

In the EU and UK, "public" does not mean "free to process". Personal data is personal data whether or not you had to log in to see it.

You need a lawful basis. For B2B prospecting that is usually legitimate interest, which requires you to actually perform and document a balancing test — not simply assert it. You owe transparency, which for indirectly-collected data generally means telling people within a month of collection or at first contact. And you must honour objection and deletion requests.

In practice, most compliant B2B programmes do the balancing test, keep records, and have a working deletion process. Most non-compliant ones have none of those and have simply not been asked yet.

Where that leaves you

A reasonable reading, and again this is not advice:

• Fetching genuinely public pages without an account is on much firmer ground than automating a logged-in session.
• Using your own credentials or cookies puts you in contractual territory and puts your account at risk.
• Data protection obligations apply regardless, and are where most real exposure sits for a European business.
• Vendor risk is real. Pick a provider whose posture you can inspect, and keep your integration portable.

We built our own acceptable use policy around that reading: public data only, no credentials, no email enrichment, and anyone can ask to be suppressed without holding an account. It constrains our marketing as much as your usage — which is, we think, the only version of such a policy worth writing.