Proxycurl Person Profile Endpoint replacement

Proxycurl is gone, so every GET against its Person Profile Endpoint now fails and your enrichment jobs are writing nulls. The replacement is POST /enrich_profile. It takes the same thing yours already has, a LinkedIn profile URL, so nothing upstream in your pipeline has to change.

Get 100 free credits — no card

Of the four Proxycurl endpoints people are migrating off, this is the cleanest. Same input type, same kind of output, different field names. Budget the afternoon for the field names, not for the call.

# Before (Proxycurl) — dead
# GET https://nubela.co/proxycurl/api/v2/linkedin?url=<profile-url>
#   -H "Authorization: Bearer $PROXYCURL_KEY"
#   Proxycurl's public docs are offline. Confirm paths against your own archived client code before you migrate.

# After (RichAPI)
curl -X POST https://api.richapi.ai/api/v1/enrich_profile \
  -H "x-api-key: $RICHAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.linkedin.com/in/example/"}'

Three mechanical changes: GET with a query string becomes POST with a JSON body, Authorization: Bearer becomes x-api-key, and the parameter is url. There is no OAuth step and no token exchange.

Both APIs return a person, but they disagree on what to call the parts of one. RichAPI's response is flat JSON with these fields:

Two differences will bite you if you skip them. RichAPI splits the name into firstname and lastname where Proxycurl carried a single full-name field, so any code doing record.full_name.split() needs deleting rather than porting. And the arrays are the part your adapter should treat as untrusted: if you were reading a nested key off a Proxycurl experience entry, check the live shape before you write the mapping.

The authority is https://api.richapi.ai/api/v1/openapi.json. Read fields off that, not off this table, because this table is a page and that is the spec.

1. Get a key. Sign up at app.richapi.ai, 100 free credits, no card.

2. Change the call. Swap host, method and auth header as shown above. If your Proxycurl client was a thin wrapper, this is a single function.

3. Write the mapping in one place. Put a from_richapi(payload) function between the API and the rest of your code, returning whatever internal person object you already use. Everything downstream then keeps compiling untouched, and when the response gains a field you edit one function.

4. Replay records you already know. Take twenty profiles where you still have the old Proxycurl output in your database, run them through the new call, and diff. That comparison tells you your real coverage on your real accounts, which no vendor page can.

Calling it from an agent works too. The hosted MCP server exposes enrich_profile as a tool in Claude, Cursor and VS Code, which is a fast way to eyeball the response shape before you write the adapter.

1 credit per call, flat. Credits are prepaid with no seats, no subscription and no contract; the per-credit rate is tiered by package size, so read yours from the pricing page.

This endpoint is not a waterfall endpoints, and every 2xx is billed, including one that comes back thin. We do have endpoints where a miss costs zero credits, email finder and email verifier among them, and this is not one of them. If you are re-enriching a stale list of 50,000 profile URLs, budget for 50,000 charges and not for the subset that resolves. 4xx and 5xx responses cost nothing on any endpoint.

A thin record here raises one question. Was there nothing to find, or did the routing go wrong? execution_log answers it, listing the sources tried, the order, and what each one returned, which is the difference between a data problem and a routing problem. Proxycurl gave you a status code and left you guessing.

Restarting a stalled CRM sync. The nightly job that hydrated contact records off LinkedIn URLs has been failing since the shutdown. Point it here, map the fields once, and the backlog drains on the next run.

Candidate screening inside an ATS. experience and education are what the screen reads, and the recruiter is looking at the record while the call happens rather than overnight.

An agent that researches a person mid-conversation. Through MCP the profile lookup is a tool call, so the agent pulls a record when it decides it needs one instead of you pre-enriching a list you hope it will use.

Is this a drop-in replacement?
The request is close to one. The response is not, because the field names differ. Plan for a mapping layer, and do not deploy a find-and-replace on a Friday.

Can I pass a vanity URL, or a URL with tracking parameters on it?
Send the clean linkedin.com/in/<slug>/ form.

Do I get charged when the profile comes back nearly empty?
Yes. A 2xx is billed on this endpoint whatever it contains. Zero-cost misses apply to the waterfall endpoints, not to this one.

What about the profiles I used to resolve from an email address?
That is a two-call chain now. See the Person Lookup migration.

How fresh is the record?
It is retrieved at request time rather than read out of a snapshot we refresh on a schedule. We do not sell an index size, because people change jobs and an index does not.

Can I call this from Claude or Cursor?
Yes, through the hosted MCP server, no install. The tool list updates itself as endpoints change.

Do I need a credit card to test the migration?
No. 100 free credits on signup.

• Proxycurl alternative: the full endpoint map — every endpoint, in one table
• Company Profile Endpoint replacement — the company-side swap, and the domain problem
• Person Lookup by email replacement — the two-call chain
• Employee Listing replacement — everyone at a company
• All endpoints — the full catalog
• Pricing — credit packages and tier rates

Run twenty profiles you already have answers for and diff them against your old output. Get 100 free credits