Bright Data for LinkedIn data versus a two-endpoint enrichment API, and where each one fits

If you are weighing Bright Data against an enrichment API for LinkedIn data, the first thing to settle is that they sit at different scales. Bright Data is a data platform that sells whole datasets and a scraper covering most of LinkedIn. An enrichment API is two endpoints you call one record at a time. That gap decides your billing, your coverage, and how much of the pipeline you own, so settle it before you compare anything per record.

A platform that covers LinkedIn, not one endpoint

Bright Data sells LinkedIn as both a bought corpus and a live scraper, and the breadth is the point. On the dataset side it advertises 905.8M+ records across LinkedIn people, companies, jobs, and posts, starting at up to $0.0025 per record with a $250 minimum order. On the scraper side its LinkedIn API takes up to 20 URLs per request and returns profiles, companies, jobs, and posts as JSON, NDJSON, or CSV, delivered by API download, webhook, or straight into S3, Snowflake, and other stores.

That coverage is a real strength when you need it. If your job is to harvest posts, list job openings, or buy a firmographic corpus in bulk, a scraper and a dataset are the right tools and a two-endpoint API is not. Be honest about your job before you compare, the same way you would when choosing among Proxycurl replacements.

It is also where the work lives. You choose between a bulk dataset and a live scrape, you manage the delivery destination, and you map whatever schema the dataset ships. Breadth on the input side means more surface to hold on the integration side.

The two models, side by side

The right-hand column is what a two-endpoint API such as Triguna is. You call GET /v1/people/profile for the person API or GET /v1/companies/details for the company API, and you get JSON back against one published schema. There is no search path, no jobs path, and no bulk endpoint, so enriching N entities is N calls. It replaces profile and company enrichment and nothing else.

Provenance you can audit, in the headers

Every enrichment response carries its origin in the headers, not in the body. A real lookup looks like this:

$ curl -sD- -H "ApiKey: $TRIGUNA_KEY" \
    "https://api.triguna.ai/v1/companies/details?company_id=acme-corp"

HTTP/2 200
X-Data-Source: live
X-Fetched-At: 2026-09-15T09:14:22Z
X-Data-Age-Seconds: 0
X-Credits-Charged: 1

X-Data-Source says whether the row was fetched live, served from a stored copy under 24 hours old, or returned as a stale_fallback during an outage. X-Fetched-At is the exact retrieval time and X-Data-Age-Seconds is how stale it is. Provenance lives in the headers, never as a "source" field in the body, so a fresh fetch and a cached one carry the same audit trail. When someone asks in six months why a record looked the way it did, that is a complete answer. The caching and provenance reference has the detail.

A bought dataset answers the freshness question differently: a row is as current as the provider’s last refresh of it. Neither model is wrong, but they are different questions, and it is worth knowing which one your integration is actually asking.

A billing and retry contract you can predict

X-Credits-Charged is on every response, so the bill is a sum you can compute rather than an invoice you wait for. One credit per answered lookup. A cache hit costs one credit, because it is the same data delivered faster. A 404 costs one credit too, because searching for an identifier that turns out to have no record is a real retrieval that ran. The company_id takes the URL slug, not the display name, which is the trap that produces most of those misses:

$ curl -sD- -H "ApiKey: $TRIGUNA_KEY" \
    "https://api.triguna.ai/v1/companies/details?company_id=Acme%20Corporation"

HTTP/2 404
X-Credits-Charged: 1

Send acme-corp and it resolves; send the name and you pay a credit for nothing. That is the first of the identifier traps worth fixing before your first call. The retry rule follows from the same contract: retry 429, 502, and 503 with backoff, and never retry a 400, 401, 402, or 404, because a retried 404 spends a credit every time. The statuses that cost nothing are fixed and published on the pricing page, not set per dataset or per run. The full cost picture is in what an enrichment run costs.

How to choose

Pick Bright Data when you need breadth and you are willing to own the pipeline: buying a corpus in bulk, scraping posts and jobs, or piping results into a warehouse. Pick a managed enrichment API when your job is to turn an identifier into a current person or company record on demand, and you want one schema, provenance on every call, and a fixed cost per lookup. Plenty of teams use both, a dataset for the wide coverage and an API for the enrichment their product runs on every signup. The company records guide shows what the company endpoint returns and why company_id behaves the way it does.

If you want to see which side fits, the five free credits on signup are enough to enrich a handful of records end to end and read the headers yourself. Two documented endpoints is a surface you can hold in your head and hand to an agent, which is the whole idea behind how the API is scoped.

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 scrapers and datasets sorted by how each actually works.
• Enrich on signup: spend the free credits and read the provenance headers for yourself.
• Pricing: one credit per answered lookup, and the status codes that cost nothing. Sign up for five free credits at app.triguna.ai/signup.

bright-datacomparisonlinkedinenrichment