Proxycurl Shut Down: Where LinkedIn Data Goes Now

Copy this line to your agent to rebuild a LinkedIn enrichment step.

set up https://monid.ai/SKILL.md and use apify /dev_fusion/linkedin-profile-scraper to enrich a list of profile URLs

Proxycurl was the default LinkedIn data API for a lot of teams, and on 4 July 2025 it announced it was shutting down to comply with a legal settlement with LinkedIn. That is a different kind of vendor loss from a price rise or an acquisition, because the reason it closed is a fact about the category rather than a fact about the company. Any replacement you pick inherits the same question. Monid is the OpenRouter for agent tools: one key and one balance across many providers, which is useful here mainly because it lets you switch the provider behind a step without switching the step.

Why did Proxycurl shut down, and what does it mean for my pipeline?

Proxycurl shut down to settle a lawsuit, not because the business failed. Founder Steven Goh wrote in the company's closing post that LinkedIn filed suit in January 2025 and that the company was closing "to comply with the legal settlement with LinkedIn", having grown to roughly a ten million dollar revenue business first. The API stopped being a going concern while it was profitable.

The reason it did not fight is the reason to read this carefully

Goh's stated calculation was not that the case was unwinnable. It was that winning was unaffordable. He points at the American Rule, that even a winning defendant generally cannot recover its legal fees, and at the fact that LinkedIn is owned by Microsoft and has, in his words, an effectively unlimited war chest.

That reasoning is worth sitting with, because it applies to every vendor in this category rather than to one of them. A LinkedIn data provider's survival depends less on the quality of its engineering than on whether it draws attention and can absorb the cost of the resulting fight. When you pick a replacement, you are picking a risk profile, not only a feature set.

What actually broke, in the order you will notice it

A profile enrichment endpoint sits in the middle of things, so its removal surfaces in stages. First the enrichment step errors. Then the CRM fields it wrote go stale rather than empty, which is worse, because nothing looks broken. Then, weeks later, somebody notices that job titles in the pipeline are from whenever the last successful run was.

The r/bigdata thread comparing Proxycurl and People Data Labs on global company profiles is a good snapshot of how teams were choosing here before the shutdown: coverage first, freshness second, price third. The shutdown reorders that list and puts a fourth item at the top.

Bulk dataset versus per-profile call: what actually differs

Most teams that used Proxycurl were doing the second thing while paying for something shaped like the first. The shutdown is a reasonable moment to check which one you actually need.

📖 See also Turn a LinkedIn Profile URL Into an Enriched Lead

How do you move a LinkedIn enrichment pipeline off Proxycurl?

The migration is easier than it looks because Proxycurl's core shape, one profile URL in and one structured record out, is the most common shape in the category. Match that shape first and worry about field parity second.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-key> -l main

Step 1. Replace the Person Profile call

What it does. Takes LinkedIn profile URLs and returns normalised structured records, which is the direct analogue of what Proxycurl's person endpoint did.

The endpoints. apify/dev_fusion/linkedin-profile-scraper accepts an array of profile URLs and returns one record each, with no result limit parameter, because the result count equals the input count.

The call.

monid inspect -p apify -e /dev_fusion/linkedin-profile-scraper
monid run -p apify -e /dev_fusion/linkedin-profile-scraper \
  -i '{"profileUrls":["https://www.linkedin.com/in/williamhgates"]}' -w

What comes back. Verified 2026-08-20: name, headline, summary, profile images and location, then arrays for work history, education, skills and endorsements, languages, certifications, publications, patents, volunteer experience and recommendations. Company metadata rides along inside the work history, including industry, website, size range, founded year and company identifiers. Contact enrichment adds discovered email and mobile where available.

That last clause is the one to test rather than trust. Email discovery is probabilistic in every product in this category, and the honest way to evaluate it is to run twenty profiles you already know the answers for.

What it costs. Per result, at cents per profile, so a hundred profiles costs a hundred profiles rather than a plan. Current figures at monid.ai/tools.

Step 2. Replace the search half, which is the harder half

What it does. Finds the profiles in the first place, by filter rather than by URL. This is the part teams forget to budget for, because Proxycurl's search and its enrichment were one signup.

The endpoints. apify/harvestapi/linkedin-profile-search filters by job title, company, school, location, industry, seniority and headcount. apify/harvestapi/linkedin-profile-search-by-name handles the narrower case where you have a name and need the right person. apify/harvestapi/linkedin-company-employees walks a company's staff with title, seniority and location filters.

The call.

monid discover -q "linkedin profile enrichment"
monid inspect -p apify -e /harvestapi/linkedin-profile-search

What comes back. Search pages, then profile detail records at the depth you asked for. The billing is tiered rather than flat, and the tiers are worth reading before you run: search pages, profile details, and profile details with email search are three separate lines.

What it costs. Per result on every tier, which means a broad filter is the expensive mistake here. Narrow the filter, then widen it once you have seen what a page of results looks like.

Step 3. Decide which company records you need live

What it does. Fills in firmographics without paying profile prices for them.

The endpoints. tikhub/api/v1/linkedin/web_v2/get_company_profile bills per call rather than per result, which suits spot checks. apollo/organizations/enrich resolves a company from a domain, LinkedIn URL, name or website and returns firmographics, funding and technology data in one call.

What comes back. Enough that the LinkedIn company page is often not the thing you needed. If your enrichment is really about company size, funding and stack, a company endpoint answers it without touching a person record at all.

What it costs. Per call for both, which is the shape you want for a step that runs once per account rather than once per lead.

📖 See also Which LinkedIn Scraper Actually Returns Emails and Automate LinkedIn Company Data Pulls Into a Table

Is scraping LinkedIn with no paid APIs actually a plan?

It is a plan that works until it is the only thing holding your pipeline up. The r/n8n post describing a workflow that pulls a thousand targeted LinkedIn leads a day with no paid APIs drew ninety-three comments, and the comments are the useful part: the build works, and the failure modes people report are account restrictions, silent partial results, and selector breakage after a layout change.

Those three failures have a shape in common. None of them raises an error. A restricted account returns a page, a partial scrape returns a shorter list, and a changed selector returns nulls. So the pipeline reports success and the data quietly degrades, which is the same failure pattern as a dead enrichment endpoint but harder to detect because there is no status code to alert on.

The trade is real and it is not free either way. Running it yourself costs engineering time and account risk, and the risk lands on an account that belongs to a person. Paying per call moves the operational burden to the provider and the legal exposure with it. Neither option makes the underlying question go away, which is why the honest framing is not build versus buy but who carries the risk when it goes wrong.

If you do run your own, the one thing worth adding is an assertion rather than a try/catch: check that the field you actually consume is populated on a known-good record every run, and fail loudly when it is not.

Which endpoint should I use for which job?

Every row verified with monid inspect on 2026-08-20. The billing column is the shape rather than a figure, because per call and per result change how you architect and a price does not stay true.

What does replacing Proxycurl actually cost?

It depends almost entirely on whether you were using the search half, and most Proxycurl bills were mostly search.

Enrichment alone is cheap and predictable. A few hundred profile URLs enriched once is single-digit dollars, and it scales linearly because the billing is per result with no plan underneath it. If your pipeline enriches the leads a human is about to work rather than every row in a database, this is the whole bill.

Search is where the number moves. Filtered search bills per result across more than one tier, so a filter that matches ten thousand people costs ten thousand people even if you only wanted the first fifty. The fix is not a cheaper endpoint, it is a narrower filter and a hard cap, checked against one page of output before the real run.

Discovery and inspection stay free throughout, so you can read every tier of the pricing before committing to a run. That is the property that makes a metered balance work for this job: access costs nothing until it is used. Where metered loses is steady high volume, and we worked that crossover through in pay per call versus subscription. Prices are at monid.ai/tools.

When should you not use Monid?

If you need a licensed dataset with contractual coverage guarantees, buy one. People Data Labs, Apollo and the other data companies sell a different product from an endpoint: a defined universe, a refresh commitment and someone to call when coverage drops. A per-call endpoint gives you none of that, and for a team building a market map rather than a workflow, that is the wrong shape entirely.

If your use case is served by LinkedIn's official APIs, use them. Marketing, advertising and Talent Solutions APIs exist, they are supported, and they carry no ambiguity at all. The limitation is scope rather than quality: they serve your own company's data and your own advertising, not arbitrary third-party profiles, which is exactly why this category exists.

If your legal position needs to be unambiguous, no endpoint in this category gives you that, ours included. The honest statement is that this is contested ground, LinkedIn litigates on it, and the outcome of the Proxycurl case is that a profitable company chose to close rather than test it. Route your decision through counsel rather than through a comparison table.

Conclusion

Proxycurl did not lose to a competitor, it settled with the platform, and that means the replacement question is not "who else does this" but "which half of this do I actually need and who should carry the risk". Teams that used Proxycurl for URL-to-record enrichment have a clean, cheap, per-result substitute available today. Teams that used it for filtered search have a real migration, because search bills differently and needs its filters re-tuned.

The thing that matters more than the endpoint choice: this category's vendors do not fail gracefully, and none of them warn you. Keep the provider in configuration, assert on a known-good record every run, and make sure a stale field alerts as loudly as an empty one. Stale is the failure mode that costs money, because nobody notices it.

The free next step costs nothing. Run monid discover -q "linkedin profile enrichment" to see what exists today, monid inspect on the two that match your two halves to read their schemas and current prices, then one small paid run against twenty profiles whose answers you already know. Start at monid.ai.

FAQ

Last updated August 2026.