Proxycurl Alternative: Replace Its LinkedIn API Calls
Proxycurl closed in July 2025. Map its people, company, jobs and search calls to replacements, with two profile endpoints run on the same URL.

Replace your Proxycurl profile lookup without rebuilding the pipeline. Paste this into your agent:
Set up https://monid.ai/SKILL.md, and then use Monid to look up this LinkedIn profile URL with two different profile endpoints, and give me a table of which fields each one returned and what each call cost.
One prompt tests a replacement before you commit. 1 min setup · 10-30 hrs saved.
Your pipeline used to call Proxycurl for LinkedIn profiles, companies, jobs or search, and now it cannot. The job is not to find "the" replacement. It is to swap each call you actually made, check that the fields your CRM or agent reads still arrive, and keep the vendor behind the call easy to change. This guide maps the usual call families to endpoints you can use today, runs two profile endpoints on the same URL and compares what came back, and lists what breaks at cutover. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.
What is the easiest way to replace the Proxycurl API?
Monid. Install it once, add a key, and your agent calls LinkedIn profile, company, job and search endpoints from several providers through the same key, with nothing to sign up for per vendor.
- Pay per call. A profile lookup is billed on its own, at $0.01 on one endpoint and $0.008 on another (Verified 2026-10-16 on the LinkedIn tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
- More than one provider behind one key. If the endpoint you pick today stops returning what you need, you change the provider and endpoint in the call, not the account, the key or the balance.
- Lives inside your agent. Install the CLI, add your key, run the prompt above, and the endpoints are there whenever the agent needs them. Your agent reads
SKILL.mdand learns the discover, inspect, run workflow itself, so setup is about a minute.
At those prices, 1,000 profile lookups is $10.00 on the first endpoint and $8.00 on the second (Verified 2026-10-16), with no seat or plan under the bill.
Why did Proxycurl shut down?
It shut down to settle a lawsuit. The company's closing post, dated 4 July 2025, says LinkedIn filed suit in January 2025 and that the company was closing to comply with a legal settlement with LinkedIn. The post says the founder judged that fighting the case was not worth it, and that the team spent the preceding weeks helping customers move off. It names a competitive intelligence product, NinjaPear, as the team's focus now.
That is a different kind of loss from a price rise or an acquisition. The reason the service closed is a fact about the category, so any provider you pick is exposed to some form of the same pressure. You cannot remove that, but three habits limit what it costs you, and the rest of this guide builds them in:
- Keep the provider and endpoint in configuration, not in code, so a swap is one line.
- Map the fields you read once, in one place, so a new provider is a new mapping and not a rewrite.
- Run a known-good profile through the pipeline on a schedule and alert when a field you use is empty. Stale data is the failure that costs money, because nothing looks broken.
Rules about collecting and using LinkedIn data differ by country and by use, so check the ones that apply to you before you build on any provider.
How do you move a LinkedIn profile lookup off Proxycurl?
Match the shape first and worry about field parity second: one profile URL in, one structured record out. That is the call most pipelines depend on, and turning a LinkedIn profile URL into an enriched lead walks the same shape end to end.
Map your calls to the replacements
Search suggestions around the old product show how people thought of it: a people API, a company API, a jobs API and a search API. Each has an endpoint you can use now.
| What you called | What replaces it | Input |
|---|---|---|
| People: one profile from a URL | ploid/linkedin/profile, tikhub/api/v1/linkedin/web_v2/get_user_profile | Profile URL |
| Company: one company from a URL | tikhub/api/v1/linkedin/web_v2/get_company_profile | Company URL |
| Jobs: postings by title and place | apify/harvestapi/linkedin-job-search | Job titles, locations |
| Search: find people by filter | ploid/linkedin/search | Keywords, location, title, current company, school |
List the calls your code actually makes before you start. Most pipelines used one or two of these four.
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-api-key> -l main
Find what is available today
monid discover -q "linkedin profile enrichment"
Discovery is free and returns each endpoint with its price and typical run time.
Replace the profile call
monid inspect -p ploid -e /linkedin/profile
monid run -p ploid -e /linkedin/profile \
--query '{"url":"https://www.linkedin.com/in/williamhgates"}'
The endpoint takes one url (a profile URL, a vanity slug or an @handle) and nothing else. One call returns one record, so the count of calls equals the count of profiles.
Replace the company call
monid run -p tikhub -e /api/v1/linkedin/web_v2/get_company_profile \
--query '{"url":"https://www.linkedin.com/company/microsoft/"}'
A company lookup is $0.008 a call (Verified 2026-10-16). This is also the call to use when your enrichment is really about company size and industry, since it answers that without touching a person record.
Replace the search call
People search is the half that gets forgotten, because it was often part of the same signup as the profile lookup. The search endpoint takes a filters object with keywords, location, title, currentCompany and school (each accepts one value or a list), a limit of 1 to 100 and a cursor for the next page:
monid inspect -p ploid -e /linkedin/search
monid run -p ploid -e /linkedin/search \
-i '{"filters":{"title":"Head of Data","currentCompany":"Stripe"},"limit":25}'
It bills per result at $0.01 (Verified 2026-10-16), so a limit of 100 is a bill of about $1.00 for a full page. Set the limit on purpose.
Give this to your agent![]()
Set up https://monid.ai/SKILL.md, and then use Monid to look up this list of LinkedIn profile URLs with the profile endpoint, map name, headline, current company and location into one table, and tell me which rows came back with an empty field.What did two replacements return for the same profile?
Two profile endpoints, one URL. We ran ploid/linkedin/profile and tikhub/api/v1/linkedin/web_v2/get_user_profile on Bill Gates's public profile on 2026-10-16. Both completed and each billed one unit. The two bills together were $0.018 (Verified 2026-10-16).
ploid/linkedin/profile | tikhub/.../get_user_profile | |
|---|---|---|
| Billed | $0.01 | $0.008 |
| Run time | about 1.7 s | about 13.6 s |
| Name | fullName | name |
| Headline | headline | position |
| About | summary | about |
| Location | location, countryCode | city, country_code, location |
| Work history | positions (3) | experience (3) |
| Education | education (2) | education (2) |
| Followers | 40,719,122 | 40,731,229 |
| Connections | 8 | 8 |
| Posts and activity | none | posts (10), activity (15) |
| Related people | none | people_also_viewed (10), similar_profiles (10) |
| Prices checked | Verified 2026-10-16 | Verified 2026-10-16 |
What the two agree on
The identity and the career. Both returned the same name, the same headline text, the same about paragraph, the same three current roles (Gates Foundation, Breakthrough Energy, Microsoft) with the same start years, and the same two schools. Either endpoint fills name, headline, current company, location and work history.
Where they differ
The shape and the extras. The first returns a tidy record with a currentPosition object, a positions array with title, companyName, companyUrl, startsAt, endsAt and a current flag, a socialId, and the isOpenToWork and isPremium flags. The second returns the same career under different names, plus the ten latest articles with their links and dates, fifteen recent activity items (nine shared, three commented, three liked), and two lists of related people.
Neither returned skills, certifications, an email or a phone number. If your old pipeline read those from Proxycurl, they are the fields to plan around; a separate enrichment endpoint is the place to look for contact details, and it bills differently.
Which one to pick
Pick on what you read. For name, role and company in a lead table, the first is a clean record in under two seconds. For a profile plus recent posts and activity, the second is one call, and its 13.6 seconds matters only if a person is waiting.
Can you scrape LinkedIn yourself instead?
Yes, people do it with a browser, a session cookie and a script, and it works until it does not. The failures are quiet: a restricted account returns a page, a partial scrape returns a shorter list, and a changed layout returns nulls, so the pipeline reports success while the data degrades. Running it yourself also means proxies or a browser setup, parsing code, retries, and a repair every time the page changes, and the risk sits on an account that belongs to a person. How to scrape LinkedIn without getting your account banned covers that trade in detail.
A call to an endpoint moves that work to the provider. The profile call returns typed JSON instead of HTML you parse, and the job-search input even carries an optional cookie field you can leave empty. Pick Monid for anything you will run more than once, and keep the DIY script for a one-off look at one page. If the data feeds an automation, the n8n data layer for scraping and enrichment shows where the endpoint call sits in the flow.
What goes wrong when you cut over?
Four things showed up in a single side-by-side run, and each would have slipped through a pipeline that only checks for errors.
Why do the field names not line up?
Because every provider names things differently, and the same data sat under four different names in our two runs. The headline was headline in one and position in the other; the about text was summary and about; the job list was positions and experience, with startsAt against start_date. Write the mapping once, in one place, and give your own code a stable record:
const toRecord = r => ({
name: r.fullName ?? r.name,
headline: r.headline ?? r.position,
about: r.summary ?? r.about,
roles: (r.positions ?? r.experience ?? []).map(p => ({
title: p.title,
company: p.companyName ?? p.company,
start: p.startsAt ?? p.start_date,
})),
});
Why do the counts disagree?
Followers read 40,719,122 on one call and 40,731,229 on the other, 12,107 apart, from two calls made 17 seconds apart. Counts like followers and connections come from whichever cache the provider read, so compare them with a tolerance, never for equality, and never use them as a join key.
Why does the URL come back different?
The second endpoint returned https://ua.linkedin.com/in/williamhgates for a profile we asked for on www.linkedin.com. LinkedIn serves the same profile under regional domains. Key your records on the public identifier (publicIdentifier or id, both williamhgates here), not on the full URL string.
How do you catch a field that goes empty?
With an assertion, not a try/catch. Some fields came back null for a famous profile: industry and coverPictureUrl on the first endpoint, honors_and_awards on the second, and the location and description of every role on the first. A null is normal for some profiles, so the check that matters is on a known-good profile you have already seen with the field filled:
const rec = toRecord(await lookup(KNOWN_GOOD_URL));
if (!rec.headline || rec.roles.length === 0) throw new Error("profile fields went empty");
Run it on a schedule, and make a stale field alert as loudly as a failed call.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Billing | Price |
|---|---|---|---|---|
ploid/linkedin/profile | One profile, full career | URL, slug or handle | Per call | $0.01 |
tikhub/api/v1/linkedin/web_v2/get_user_profile | One profile plus posts and activity | Profile URL | Per call | $0.008 |
tikhub/api/v1/linkedin/web_v2/get_company_profile | One company record | Company URL | Per call | $0.008 |
ploid/linkedin/search | People by filter, up to 100 a page | Keywords, title, company, school, location | Per result | $0.01 |
apify/harvestapi/linkedin-job-search | Job postings by title and place | Titles, locations | Per result plus a flat fee | Set maxItems on purpose |
anyapi/linkedin.profile | One rich profile, with a choice of route | Profile URL | Per call, priced by route | Read monid inspect |
| Prices checked | Verified 2026-10-16 |
The profile rows were run on 2026-10-16; the search, job and company rows were inspected, and the billing shape is what you plan around. For the full picture of what each LinkedIn endpoint returns across companies, people and jobs, see the LinkedIn scraper API guide. Current prices are on monid.ai/tools.
When is another route a better fit?
You need a licensed dataset. If you want a defined universe of people or companies with a refresh schedule and someone to call when coverage drops, that is a different product from an endpoint. Database vendors often quote by the seat or by the record, and they suit a market map better than a workflow. People Data Labs, Apollo and ZoomInfo compared lays out the trade, and dataset versus API for B2B data covers when each fits.
You need skills, certifications or contact details on every profile. Neither profile endpoint we ran returned them. Plan a separate enrichment step for emails and phones, and expect it to bill by what it finds.
You need a single-vendor contract. Each endpoint on Monid is run by a different company. If procurement needs one party to sign for the whole chain, a direct contract with one vendor is simpler.
We resell these endpoints, so the part worth keeping is the habit and not the vendor: keep the provider in configuration, map the fields once, and assert on a known-good record.
Conclusion
The way to replace Proxycurl is to replace the calls you actually made, one at a time, through Monid: a profile from a URL at $0.01 or $0.008 (Verified 2026-10-16), a company at $0.008, people search per result. One key and one balance cover all of them, setup is about a minute, and the endpoints are ready inside your agent whenever a step needs one.
Two things matter more than which endpoint you pick. First, the field names differ, so write the mapping once and give your code a stable record. Second, an endpoint can return the wrong thing without raising an error, so assert on a known-good profile on a schedule. Our two runs disagreed on follower counts by 12,107 and on the URL domain, and neither disagreement was an error.
How we estimated the time saved: replacing two or three call families (profile, company, search) is roughly 5 to 10 hours each for finding the endpoint, mapping fields, running a side-by-side test and wiring the check. That is 10 to 30 hours. The 1 minute is the install, key and first call once you already have a Monid key.
The free next step: run monid discover -q "linkedin profile enrichment", monid inspect on the two profile endpoints, then one small paid run on a profile whose answers you already know, and print the fields you read next to each other. Start at monid.ai.
FAQ
What is the best LinkedIn scraper API?
There is no single best one, because LinkedIn data splits into profile lookups, company lookups, job search and people search, and different endpoints suit each. Pick on the fields you read and the billing shape you can plan around. The breakdown by job is in the table above.
Is there a free Proxycurl alternative?
Not free, but you pay only for what you run. Through Monid a profile lookup is $0.01 (Verified 2026-10-16), with no monthly plan and no minimum, and discovery and inspection cost nothing. Free scrapers exist as browser extensions and open source scripts, and they suit a single page by hand, not a list or an agent.
Does the official LinkedIn API replace Proxycurl?
Only for data you already have a relationship with. LinkedIn's official products cover your own company page, your own advertising and your own recruiting workflows. They do not look up an arbitrary person's profile, which is the call most Proxycurl pipelines made.
Is the data I already pulled from Proxycurl still usable?
That is a question for your own legal advisor, because the rules differ by country and by how you use the data. The closing post is silent on stored data, so do not assume anything either way. Plan to refresh old records through a live endpoint either way.
Published August 2026.


