LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Calendar
Join Slack CommunityProxycurl shut down, 4 July 2025
Proxycurl Alternative: What Happened, and How to Replace It in 2026
Proxycurl closed on 4 July 2025, months after LinkedIn sued its parent company, Nubela, over how the profile database behind it was built. If your product enriched LinkedIn profiles through that API, the dependency is gone, and the real question is no longer just which proxycurl alternative is cheapest. It is whether the one you pick next is built on the same exposure that shut this one down.
The short answer
Build on the LinkedIn API freeProxycurl built and resold a database of LinkedIn profiles collected outside any authenticated member's own access, the exact pattern LinkedIn's suit targeted. An account-based API such as Unipile retrieves data on behalf of each end user's own linked LinkedIn account, scoped to what that member can already see, with no independent profile database behind it. That structural difference, not the price list, is what decides whether a replacement inherits the same risk.
Table of Contents
WHAT IT CHANGES
CHOOSING A REPLACEMENT
BUILD WITH UNIPILE
What happened to Proxycurl, and when
Proxycurl, run by a company called Nubela, sold API access to LinkedIn profile and company data: a developer sent a LinkedIn URL and received structured fields back, no browser session and no manual lookup required. It was one of the more widely used LinkedIn data APIs among SaaS builders, and by its own founder's account it was doing roughly 10 million USD in annual recurring revenue when the case that ended it was filed.
| Date | What happened |
|---|---|
| January 2025 | LinkedIn files a federal suit against Nubela, alleging hundreds of thousands of fake accounts were created to collect millions of LinkedIn profiles, which Proxycurl then resold through its API. |
| Mid-2025 | The case settles, with data deletion obligations placed on Nubela. |
| 4 July 2025 | Proxycurl shuts down. Founder Steven Goh writes publicly: "there is no winning in fighting this." |
| After July 2025 | Nubela relaunches under a new brand, Enrich Layer. |
The founder's own explanation for not fighting the suit points to the American Rule: even a company confident it would eventually win cannot recover its legal costs, which makes a prolonged fight against a much larger legal budget a losing proposition regardless of the merits. Whatever a replacement promises on price or coverage, that same asymmetry applies to any provider building on the same model.
Proxycurl was not an isolated case
The Nubela suit fits a pattern that predates it and has continued since. Three cases, three years apart, all target the same underlying structure: a profile database built independent of any authenticated LinkedIn member's own session.
hiQ Labs v. LinkedIn, December 2022: after years of litigation, a consent judgment ordered hiQ to pay 500,000 USD and to permanently stop collecting LinkedIn data, and to delete its code and derived data. hiQ no longer exists.
LinkedIn v. Nubela (Proxycurl), January to July 2025: covered above.
LinkedIn v. ProAPIs, filed 3 October 2025: LinkedIn alleges an "industrial-scale fake account mill" reselling access for up to 15,000 USD a month per client, which it says it detected "within hours."
None of this means every LinkedIn data provider gets sued. It means the risk is structural, not incidental: it attaches to a specific way of building the data, not to any one company's size or intentions. The public record behind that structural risk is laid out in our guide to whether LinkedIn scraping is legal.
What the shutdown means if your product depended on Proxycurl
Proxycurl's founder described the shutdown as immediate, not phased. For a product that called its API to enrich profiles, that has three concrete consequences.
Calls fail now. Any enrichment step that depended on Proxycurl's endpoints returns errors, with no migration window from the vendor side.
Stored fields go stale. Whatever profile data you retrieved and cached before 4 July 2025 stops updating. Job titles, headlines, and connections keep changing on LinkedIn; your copy of them does not.
The choice of replacement now matters more than the speed of migration. The section above shows this is a recurring pattern, not a one-off. Picking a replacement that reproduces the same data model buys time, not safety.
The pattern that should shape whatever you pick next
Every case above targets the same structure: a database of profiles built outside any authenticated member's own session and resold to third parties. A replacement that reproduces that structure inherits the same exposure, whatever its price or field coverage looks like on a comparison page.
Enrich Layer, and the successor question
Nubela did not disappear. The company relaunched under a new name, Enrich Layer, according to its own founder's shutdown announcement. What is not publicly documented is whether the data underneath the new brand is built any differently from what triggered the original suit.
That is not a claim this page can make either way, and it should not be the deciding factor for a rebrand any more than for a brand-new alternative you have never heard of. The honest answer is to apply the same check to Enrich Layer that the next section applies to every option: ask where the data comes from, not what the product is called.
What to check before choosing a Proxycurl alternative
Most comparison pages rank the options by price per lookup or by how many fields they return. Neither question predicts whether the provider survives the next three years. The question that does is simpler: is the data retrieved live, on behalf of a real authenticated user, or pulled from an index the provider built and owns.
What it did well
No end-user authentication to build. One API key, and any profile in the index was reachable.
Worked at list scale, including on people nobody in your product had any relationship with.
Per-credit pricing that was simple to model and to pass on to your own customers.
Fast to integrate: a single HTTP call, no account linking flow to design or maintain.
Where it broke
One shared index meant one shared point of failure, which is what ended the service on 4 July 2025.
The provider's legal exposure was inherited by every customer at once, with no warning.
Freshness depended on when the index was last built, not on the member's own view.
Read only. No way to send a message, an invitation, or any action back to the platform.
The trade-off: the model was easy to adopt precisely because it asked nothing of the end user, and that same property is what concentrated the risk in one place.
What it does well
Retrieval and actions run on behalf of the authenticated member who linked their own account.
Exposure is scoped per linked account instead of pooled into a single company-wide index.
Read and write: retrieve a profile, send a message, manage invitations, in the same integration.
The data reflects what that member can see now, not a snapshot from an earlier crawl.
What it will not do
Each end user has to link their account, so there is an onboarding step to design and support.
Scope is bounded by what that member can already see, so it does not replace list-wide enrichment of people nobody is connected to.
Volume follows the platform's own per-account limits, and cadence stays a customer-side decision.
If your product has no logged-in user in the loop at all, this model is not the right fit.
The trade-off: asking each member to link their own account is real work, and it is what keeps the integration scoped, auditable, and independent of any single index staying online.
| Question to ask | Pre-built database | Account-based API |
|---|---|---|
| Who is authenticated | Nobody, at request time. Data was collected independent of any member session. | The end user, through their own linked LinkedIn account. |
| What it can retrieve | Any profile in the index, regardless of the requesting customer's relationship to it. | What the authenticated member's own account can already see. |
| If the provider is sued | Every customer's integration depends on one shared index that can disappear overnight, as happened on 4 July 2025. | Exposure is scoped per linked account, not pooled into one company-wide asset. |
Data Handling NoteNo independent profile database behind the API
Live retrieval, on behalf of the authenticated user: profile and message data is retrieved through the linked account's own session, scoped to what that member can already see, not indexed into a standalone Unipile database.
No parallel archive: Unipile does not build or resell a database of LinkedIn profiles. What moves through the API reaches your product; it is not retained as a separate asset.
Per-account isolation: each linked LinkedIn account operates independently. Nothing is shared across your customers' accounts.
Is a service like Proxycurl legal in 2026
Is Proxycurl legal is the wrong question by itself, because legality and LinkedIn's own enforcement are two separate tracks that can point in different directions at once.
The law: the Ninth Circuit found in hiQ Labs v. LinkedIn that collecting publicly visible data does not, by itself, violate the CFAA. That finding still stands.
The contract: hiQ won that narrow point and still lost the case under contract law, then shut down under a December 2022 consent judgment. LinkedIn's User Agreement, Section 8.2, prohibits automated data collection regardless of what the CFAA allows, and LinkedIn's own page on prohibited software and extensions confirms accounts that breach it "risk having their accounts restricted or shut down."
The enforcement: the Nubela and ProAPIs suits show LinkedIn acting on the contract track directly, independent of any CFAA question, and independent of how many years a provider has been operating without incident.
A tool can be defensible under one legal framework and still lose its LinkedIn access under LinkedIn's own Terms of Service. That gap between the two tracks is exactly what made hiQ's Ninth Circuit finding a partial win that still ended in a shutdown.
How Unipile responds, mapped to what Proxycurl covered
To be direct about the honest limit here: Unipile is not a drop-in replacement for looking up any of millions of profiles you have no relationship to, the way Proxycurl was. Unipile is an account-based API. Each end user links their own LinkedIn account through a hosted authentication flow, and every retrieval or action afterward runs on behalf of that authenticated member. If your product needs to resolve an arbitrary profile regardless of the requesting user's own connection to it, that capability envelope is genuinely different by design, and that difference is the point of this page, not a caveat to skip past.
For the enrichment work most Proxycurl-dependent products actually ran, the mapping looks like this:
CRM enrichment: instead of a background job pulling from a static index, the profile a rep is already viewing, or a contact already linked in the CRM through their own account, is retrieved live and synced onto the record, on a per-user basis.
ATS and recruiting: candidate profile lookups run against the recruiter's own linked account. Because Unipile is account-based rather than read-only, the same linked account can also send a connection request or message, a capability Proxycurl never offered.
Sales and lead tooling: profile and message data resolve for the rep's own linked account, on a schedule your product controls, without the shared-index dependency described above.
// Server-side, on behalf of the authenticated user's linked account
const res = await fetch('https://api.unipile.com/api/v1/users/' + profileId + '?account_id=' + linkedAccountId, {
headers: { 'X-API-KEY': apiKey }
});
// Returns what that linked account can already see, live
Platform Limits & Responsible UseAn account-based model does not remove LinkedIn's own limits
Limits are relayed, not removed: retrieval and messaging stay inside the same connection, search, and messaging limits a member would hit inside LinkedIn's own interface.
Cadence and volume stay a customer-side decision: the API executes what your product and your users decide to send, on a per-user basis. It does not set a pace on their behalf.
One integration, one schema, across LinkedIn, WhatsApp, Instagram, Telegram, email, and calendars. Hosted authentication and webhooks instead of a static index that can disappear on one filing date.
Start buildingHow Unipile OperatesNo shared credentials, no elevation of access
Independent technical intermediary: Unipile acts on behalf of each authenticated user, within a session that belongs to them, not as a data reseller and not on LinkedIn's behalf.
Each linked account is isolated: no credentials are shared across your customers, and one linked account cannot see another's data.
Not affiliated with, endorsed by, or sponsored by LinkedIn. LinkedIn is a trademark of LinkedIn Corporation.
The model question above, not the feature list, is what separates a durable proxycurl alternative from one quietly carrying the same exposure forward.
Three places to go deeper: the guide to retrieving LinkedIn data into your own software covers the retrieval side end to end, how the main LinkedIn API options compare if you are weighing more than one provider, and whether a free LinkedIn API tier exists alongside how LinkedIn API pricing works once the structural question above is settled.
Proxycurl alternative: your questions answered
What happened to Proxycurl, what the shutdown means, and how an account-based API differs.
Proxycurl, run by Nubela, was a LinkedIn data API doing roughly $10M in annual revenue. LinkedIn filed suit in January 2025 alleging hundreds of thousands of fake accounts were used to collect millions of profiles for resale through the API. Proxycurl settled and shut down on 4 July 2025, its founder writing that "there is no winning in fighting this."
Legality and LinkedIn's own enforcement are two different questions. The Ninth Circuit found in hiQ Labs v. LinkedIn that collecting publicly visible data does not by itself violate the CFAA, but hiQ still lost under contract law and shut down after a December 2022 consent judgment. A service can be defensible under one legal framework and still lose its LinkedIn access under LinkedIn's Terms of Service, which is what happened to Proxycurl regardless of the CFAA question.
LinkedIn's January 2025 complaint against Nubela alleged that hundreds of thousands of fake accounts were created to collect millions of LinkedIn profiles, which Proxycurl then resold through its API to third parties, in breach of LinkedIn's User Agreement.
No. Proxycurl shut down on 4 July 2025 and its API calls fail. Any profile data your product cached before that date stops updating and grows stale, since LinkedIn profiles keep changing after the fact.
Enrich Layer is the brand Nubela, Proxycurl's parent company, relaunched under after the shutdown. Whether the data behind the new brand is built any differently from what triggered the original suit is not publicly documented. Apply the same check described in this guide, where the data comes from, to Enrich Layer as you would to any other option you consider.
Check where the data comes from before comparing price or field coverage. A provider that collects and indexes profiles independent of any LinkedIn member's own session carries the same exposure that ended Proxycurl, hiQ, and the case LinkedIn brought against ProAPIs. An account-based API that retrieves data on behalf of each authenticated user's own linked account does not share that single point of failure.
No, and it should not claim to. Proxycurl could look up any profile in its index regardless of the requesting customer's relationship to it. Unipile is an account-based API: retrieval runs on behalf of the authenticated end user's own linked LinkedIn account, scoped to what that member can already see. It is a different model with a different capability envelope, built to avoid the exposure described in this guide rather than to copy Proxycurl's reach.
No. Data is retrieved live, on behalf of the authenticated user, through their own linked account's session, and passed to your product. Unipile does not build or resell a standalone database of LinkedIn profiles, and each linked account is isolated: nothing is shared across your customers' accounts.
No. Unipile is an independent technical intermediary, not affiliated with, endorsed by, or sponsored by LinkedIn. It acts on behalf of each authenticated user within a session that belongs to them, not on LinkedIn's behalf. LinkedIn is a trademark of LinkedIn Corporation.
Still have questions? Our team is here to help.
Build a LinkedIn data layer that does not share Proxycurl's exposure
Build your first integrationHosted authentication, retrieval on behalf of each linked account, and one schema across LinkedIn, WhatsApp, Instagram, Telegram, email, and calendars. No credit card to start.
Sources
9 references, September 2026Every date and figure on this page traces to the source below. Cases settle and companies rebrand without notice, so treat this as a snapshot, not a permanent status.
NubelaThe founder's own shutdown announcement, 4 July 2025, including the Enrich Layer relaunch.
StartupHubCoverage of the Proxycurl shutdown, including revenue context.
The RecordLinkedIn v. ProAPIs, filed 3 October 2025.
hiQ Labs v. LinkedInCase history via Wikipedia and the December 2022 consent judgment.
Ninth CircuitThe April 2022 appellate ruling on the CFAA question in hiQ v. LinkedIn.
LinkedIn HelpProhibited software and extensions, the official policy referenced in the legal section.
LinkedIn User AgreementSection 8.2, the contractual basis for LinkedIn's enforcement actions.
Unipile, connecting accountsThe hosted authentication flow referenced throughout this guide.
Unipile developer docsFull API reference and getting started guide for the LinkedIn integration.
Last updated September 2026. Unipile is an independent technical intermediary and is not affiliated with, endorsed by, or sponsored by LinkedIn. Volume, cadence, and content of any action taken through the API remain a customer-side decision, consistent with LinkedIn's Terms of Service and applicable data protection regulations (GDPR).
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL 
TR