Is LinkedIn scraping legal in 2026?

This is not legal advice. It is a plain-language summary of where the case law stands in August 2026, written so you can ask your own lawyer the right questions instead of none at all.

What hiQ v. LinkedIn actually decided

In 2022, the Ninth Circuit reaffirmed that scraping data a website makes publicly available, no login required, likely does not violate the Computer Fraud and Abuse Act’s “without authorization” clause (Fenwick summary). That ruling is still the baseline: public data is not automatically a federal crime to collect.

But hiQ did not walk away a winner. The case dragged through district court, the Ninth Circuit twice and the Supreme Court, and ended in a settlement where hiQ paid LinkedIn $500,000, agreed to destroy the scraped data, and accepted a permanent injunction (case history). The CFAA question was answered in hiQ’s favor. The company still lost, because CFAA was never the only claim on the table: breach of contract (the user agreement you accept to use LinkedIn at all) survived and did the real damage.

That distinction is the one people miss when they cite “hiQ” as a blanket green light.

LinkedIn is still suing, and settling, in 2026

Two recent cases show the CFAA precedent has not stopped LinkedIn from litigating:

• LinkedIn v. Proxycurl / Nubela (filed January 2025, Northern District of California): Proxycurl settled with LinkedIn.
• LinkedIn v. ProAPIs (filed October 2025): LinkedIn alleged an “industrial-scale” operation using fake accounts to access member data, including some content behind the login wall. The two sides reached an agreement in principle in February 2026, terms undisclosed (reporting on the settlement).

Notice the pattern: the disputes that go to court and get settled almost always involve fake accounts, logged-in access, or data behind authentication, not plain public profile pages. That is consistent with the CFAA line drawn in hiQ. It is also a reminder that LinkedIn will litigate against companies that build a business on its data, public or not, and that a settlement can still cost you the product.

Public data vs. data behind login

This is the distinction that matters more than any single ruling:

• Public profile pages, visible to a logged-out visitor or indexed by search engines, sit closer to the hiQ precedent. Scraping them is unlikely to trigger CFAA liability on its own.
• Anything requiring a login, a fake account, or bypassing an access control, sits on the other side of the line the ProAPIs complaint describes, and is the fact pattern LinkedIn’s litigation targets directly.

Terms of Service violations and breach of contract claims apply regardless of which side of that line you are on, and they are a separate legal question from the CFAA. Read them, or have counsel read them, before building a product around this data.

GDPR and CCPA, briefly

If the profiles you collect belong to individuals in the EU/UK or California, “public” does not work the same way in both laws:

• GDPR has no exemption for public data. It treats scraped personal data as personal data regardless of source. You need a lawful basis to process it (legitimate interest is the common argument, but it requires a genuine balancing test), and data subjects retain rights to access, correct and delete their information.
• CCPA/CPRA gives California residents similar rights over personal information a business collects, but “personal information” excludes “publicly available” information (Cal. Civ. Code 1798.140(v)(2)): information lawfully made available from government records; information the business has a reasonable basis to believe was lawfully made available to the general public by the consumer or by widely distributed media; or information made available by a person the consumer disclosed it to, if the consumer did not restrict it to a specific audience. It is an exclusion with limits, not a general license to scrape: the information must be lawfully public, and it does not cover biometric information collected without the consumer’s knowledge.

Under GDPR, “it was public” is a factor, not an exemption. Under CCPA it matters only if the information fits that definition.

What our /linkedin endpoint does

FastAF’s /linkedin endpoint returns structured data from public LinkedIn person profiles, the kind visible without logging in, for 60 credits per request:

import requests

API_KEY = "faf_live_..."  # your FastAF key

resp = requests.get(
    "https://api.fastaf.co/v1/linkedin",
    params={"id": "williamhgates", "type": "profile"},
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=60,
)
resp.raise_for_status()
print(resp.json())

The optional type parameter only accepts profile; company and job lookups are not supported. The premium flag is optional. We do not access data behind a login wall, and we do not use fake accounts. That keeps the endpoint on the public-data side of the line the case law above describes, but it does not make your specific use case automatically compliant: what you do with the data, at what volume, and for which individuals, is a separate analysis.

The short version

Public LinkedIn data is not automatically a CFAA violation after hiQ, but breach of contract and GDPR are separate questions that public data does not answer for you (CCPA excludes only information that is lawfully public, within narrow limits), and LinkedIn continues to litigate against companies it believes crossed the line. Talk to a lawyer about your specific use case before you scale it. See our docs for what the /linkedin endpoint returns, or pricing for the credit cost at volume.