Proxycurl alternatives: how the replacements actually differ, and where Triguna fits

Proxycurl shut down on 4 July 2025, after LinkedIn filed suit against its parent company in January 2025. Its users are picking a replacement now, and the shortlist is confusing because the options are not the same kind of thing. Some fetch a page live, some match against a stored dataset, and some drive a logged-in account. Pick the wrong model and you will rebuild your integration twice.

Here is the field sorted by how it actually works, then an honest account of the one slot Triguna fills and the several it does not.

Three models, not one category

Every Proxycurl alternative falls into one of three groups. The group decides your latency, your freshness, and how your input is shaped, so choose the group before you compare vendors inside it.

A real-time scraper such as Bright Data returns profiles, companies, jobs and posts as structured JSON and takes up to 20 URLs per request. A dataset provider such as People Data Labs matches your input one-to-one against roughly three billion person profiles, so it answers instantly but only for entities already in the corpus. Coresignal publishes similar coverage on the company side. An account-based API is a different risk profile entirely, because the actions run through a LinkedIn login you supply.

Proxycurl straddled the first two models across twenty-one endpoints. No single replacement covers all of it, which is why the migration is a decomposition, not a swap.

Where Triguna sits, stated plainly

Triguna is a real-time enrichment API, but you key it by identifier rather than by URL. You call GET /v1/people/profile or GET /v1/companies/details, and you get structured JSON back. Two endpoints, plus a balance check. There is no search path, no employee-listing path, and no jobs path, so it replaces exactly two of Proxycurl’s twenty-one endpoints: Person Profile and Company Profile. The full endpoint mapping, with before and after code, is in migrating off Proxycurl.

If your Proxycurl usage was search, role listing, or job scraping, a real-time scraper or a dataset provider is your replacement, not Triguna. Be honest with yourself about that before you compare anything else.

The axes that surface after you integrate

Per-record price is visible on day one. These four are not, and they are what actually cost you time in month three.

Provenance you can audit. Every Triguna response carries X-Data-Source, X-Fetched-At, and X-Data-Age-Seconds. When someone asks in six months why a record looked the way it did, the headers answer with the source and the exact retrieval time. Provenance lives in the headers, never as a "source" field in the body, so it is the same on a fresh fetch and a cached one. That is the whole argument in store the raw payload.

A billing contract you can predict. One credit per answered lookup. A 404 costs a credit because searching for an identifier that turns out to have no record is a real retrieval. A cache hit costs a credit too, because it is the same data delivered faster. The statuses that cost nothing, 400, 401, 402, 429, 502, and 503, are listed on the pricing page rather than left for you to discover on an invoice.

Error semantics that tell you whether to retry. Retry 429, 502, and 503 with backoff. Never retry 400, 401, 402, or 404, because a retried 404 bills every single time. The status code is the instruction, so your integration does not need a heuristic to decide.

A surface you can hold in your head. Two endpoints and a documented header set is a contract you can read in one sitting, which matters more than it sounds when you hand the API to an agent. api.triguna.ai/llms.txt and api.triguna.ai/v1/openapi.yaml describe the whole thing, and the agent workflows guide shows how a tool definition maps onto it.

A short decision list

1. You need search, employee listing, or jobs. Use a real-time scraper or a dataset provider. Triguna does not have those endpoints.
2. You have LinkedIn URLs and want a live page fetch. A real-time scraper matches your input shape directly.
3. You want a stored corpus and can accept its coverage gaps. A dataset provider answers instantly for entities it already holds.
4. You are replacing Proxycurl’s profile and company lookups and want a stable contract. Key Triguna by identifier and read the provenance out of the headers. Watch the identifier traps: store entity_urn, and give company_id the URL slug, not the display name, or the lookup 404s and still costs a credit.

The scrapers vanish when the source blocks them, which is the failure mode Proxycurl users just lived through. We wrote about designing for that in when your enrichment provider goes dark, and the about page explains why a small, documented surface is the position we chose to hold.

Next

• Migrating off Proxycurl: the endpoint mapping and before and after code for the two calls Triguna replaces.
• Person API: what GET /v1/people/profile returns and the identifier it expects.
• Company API: the company fields, and why company_id takes the slug rather than the name.
• Pricing: one credit per answered lookup, and the status codes that cost nothing.
• Agent workflows: handing the two-endpoint contract to an agent.

proxycurlcomparisonenrichment