Blog
ScrapIn vs an on-demand enrichment API: real-time scraping or a two-endpoint contract
ScrapIn is a real-time scraping layer with a broad surface. An on-demand enrichment API does two endpoints with provenance in the headers. When each fits.
If you are weighing ScrapIn against an on-demand enrichment API, the useful question is not which one scrapes better. It is how wide a surface you want to own and where you want the provenance to live. ScrapIn is built to be a broad data layer. An enrichment API like Triguna is two endpoints and a billing contract. Those are different bets.
What ScrapIn is
ScrapIn positions itself as a
“B2B Data Intelligence Layer for AI” that returns “structured data on
professionals and organizations, refreshed continuously and built for scale.” Its own homepage
advertises 98.8% uptime, 300M requests per month, and sub-two-second response
times. The API is served from https://api.reversecontact.com/v2/,
authenticates with a Bearer token, and a first call looks like this, from
its documentation:
curl -X POST https://api.reversecontact.com/v2/fetch/persons \
-H "Authorization: Bearer ${RC_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"url": "https://www.linkedin.com/in/janedoe"}'
Two things in that shape matter for the comparison. It is a POST with a JSON body, and it takes
a full profile URL as input. ScrapIn also documents live endpoints that
“reply immediately with a webhookId, then deliver the actual result once it is
ready”, so part of its surface is asynchronous: you get a
handle now and the data arrives at a webhook later.
What an enrichment API is instead
Triguna is a GET you key by identifier, and it answers in the same call. There is no webhook to
catch and no callback to wire.
curl "https://api.triguna.ai/v1/people/profile?entity_urn=ACoAAB1234" \
-H "ApiKey: $TRIGUNA_KEY" -i
HTTP/1.1 200 OK
X-Data-Source: live
X-Fetched-At: 2026-09-16T11:02:41Z
X-Data-Age-Seconds: 0
X-Credits-Charged: 1
X-RateLimit-Remaining: 9
The whole surface is two enrichment endpoints, GET /v1/people/profile and
GET /v1/companies/details, plus GET /v1/credits for balance. There is no search path, no
employee listing, and no bulk endpoint, so enriching N entities is N calls. That is the honest
trade: ScrapIn covers more kinds of request, and this covers two and asks you to hold the whole
thing in your head. If your job needs discovery or search, ScrapIn’s wider surface is the reason
to pick it, and a two-endpoint API is not your tool.
The real fork: where provenance and quota live
This is the difference you will feel on every single call, not just the first one.
ScrapIn returns request and account state inside the JSON body. Its response envelope carries a
metadata object with a request ID and execution time and a quotas object with
“your remaining credits and rate limit status”, alongside
success, data, and error. That is a clean shape, and it means the body is the single object
you parse.
Triguna puts provenance in the headers and never in the body. X-Data-Source says whether the row
was fetched live, served from a store under 24 hours old, or returned as a stale_fallback during
an outage. X-Fetched-At and X-Data-Age-Seconds say exactly how old it is. X-Credits-Charged
and X-RateLimit-Remaining report cost and headroom. The body is only the record.
| Axis | ScrapIn | Triguna |
|---|---|---|
| Surface | Broad: persons, organizations, search, email finder | Two endpoints, plus a balance check |
| Verb | POST with a JSON body | GET keyed by identifier |
| Input | A profile URL | A stored identifier (entity_urn, company_id slug) |
| Delivery | Sync plus async live endpoints via webhookId | Synchronous, one call |
| Provenance and quota | In the body (metadata, quotas) | In the headers, never the body |
| Auth | Authorization: Bearer | ApiKey header |
Neither placement is wrong. Body-side quota is convenient when you already parse the whole object. Header-side provenance is what lets you log the source and age of a record without deserializing the payload, and it is the same shape whether the row came from a live fetch or a cache. We wrote up the full set in what the enrichment response headers tell you.
Cost is not the axis here
ScrapIn publishes a $30 seven-day trial and pay-as-you-go credits starting from $500, with custom annual pricing above that. Triguna is $0.005 per credit and gives you five credits on signup with no card. Those are different pricing shapes for different volumes, and picking a data provider on headline price alone is how you end up migrating twice. Compete instead on what is documented and stable: whether a miss costs you, when a cached copy is served, and whether an error tells you to retry.
On that last point, the contract matters more than the rate card. Triguna charges one credit for a
404, because a lookup that turns out to have no record is still a real retrieval that ran, and it
charges nothing for a 400, 401, 402, 429, 502, or 503. That rule tells you exactly what
to retry: back off on 429, 502, and 503, and never retry a 404, because a retried 404
costs a credit every time. The reasoning is in which enrichment errors to
retry, and the full price picture is in
what an enrichment run costs.
The input trap that catches everyone
ScrapIn takes a profile URL. Triguna takes a stored identifier, and that is a real change to your
integration, not a formatting detail. Store the entity_urn value; the urn:li: prefixed form is
rejected as input. For companies, company_id takes the URL slug, so acme-corp resolves and
“Acme Corporation” returns a 404 that still costs a credit. If you are moving from a
URL-in, JSON-out scraper, budget for the identifier mapping before your first batch. The traps
worth fixing up front are in why your enrichment lookup returns
404.
A short decision list
- You need to search, list, or discover entities you cannot name yet. ScrapIn’s broad surface is your tool, and a two-endpoint API is not.
- You can name the record and want its current state. Enrich on demand, keyed by identifier, and read the source and age out of the response headers.
- You want provenance without parsing the body. Header-side
X-Data-SourceandX-Fetched-Atare the reason to prefer the enrichment shape. - You want a surface small enough to hand to an agent. Two documented endpoints is a contract you can read in one sitting, which is the whole idea behind the about page.
Start on the five free credits before you wire up billing. The pattern for calling the API once at account creation without slowing signup down is in enrich on signup.
Next
- Person API: what
GET /v1/people/profilereturns and the identifier it expects. - Company API: the company fields, and why
company_idtakes the slug rather than the name. - Proxycurl alternatives compared: the wider field of replacements sorted by how each one actually works.
- Enrich on signup: calling the API once at account creation without blocking a new user.
- Pricing: one credit per answered lookup, and the status codes that cost nothing. Sign up for five free credits at app.triguna.ai/signup.