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.

The Triguna team 16 September 2026

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.

AxisScrapInTriguna
SurfaceBroad: persons, organizations, search, email finderTwo endpoints, plus a balance check
VerbPOST with a JSON bodyGET keyed by identifier
InputA profile URLA stored identifier (entity_urn, company_id slug)
DeliverySync plus async live endpoints via webhookIdSynchronous, one call
Provenance and quotaIn the body (metadata, quotas)In the headers, never the body
AuthAuthorization: BearerApiKey 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

  1. 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.
  2. 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.
  3. You want provenance without parsing the body. Header-side X-Data-Source and X-Fetched-At are the reason to prefer the enrichment shape.
  4. 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/profile returns and the identifier it expects.
  • Company API: the company fields, and why company_id takes 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.

comparisonscrapinlinkedin-dataenrichment

Start with one request

Free credits on signup, no card required. Usage-based pricing after that.