B2B Data Providers: Buy the Dataset or Call the API?

Copy this line to your agent to enrich a company from its domain without buying a seat anywhere.

set up https://monid.ai/SKILL.md and use pdl /v5/company/enrich to fill in a company record from its website domain

Every B2B data provider sells you the same underlying thing: rows about companies and the people in them. What they actually differ on is the delivery contract. A dataset arrives as a file you now own and now have to keep fresh. An API leaves the file with the vendor and charges you per lookup. Choosing between them is not a price comparison, it is a decision about who carries staleness and who pays for the records nobody ever reads. This guide sorts that out with live responses, using Monid, the OpenRouter for agent tools.

What is a B2B data provider?

A B2B data provider is a company that maintains a database of businesses and their employees and sells you access to it. That covers three products that behave nothing alike, and the confusion between them is why buying cycles in this category run so long.

The seat product

ZoomInfo, Apollo, Cognism and the rest of the sales intelligence category. You buy licences for named users, who log into a web application, build lists, and export a capped number of contacts per month. The database is the asset; the seat is the meter. Priced annually, negotiated, and almost never sold by the record.

The dataset product

A bulk file, or a stream of them, delivered to your storage. Company records, employee records, job postings, sometimes the entire firmographic universe. Bright Data and People Data Labs both sell this shape. You get everything, you own the copy, and from the moment it lands it starts going out of date at whatever rate the underlying reality changes.

The API product

You send an identifier, a domain or a LinkedIn URL or a name, and get one record back. Nothing is delivered, nothing is stored on your side unless you store it, and the charge is per lookup or per record returned. This is the shape that fits an agent, because there is nothing to provision in advance.

The mistake worth avoiding is treating these as three price points for one product. They are three different answers to "who holds the copy", and that question determines the cost curve, the freshness behaviour and the compliance surface all at once.

📖 See also People Data Labs, Apollo, ZoomInfo: Which Should You Actually Buy?

Why is ZoomInfo so much more expensive than other sales intelligence providers?

Because you are not paying for the data, you are paying for a seat, and seats price against the value of the workflow rather than the cost of the record. A salesperson who closes one extra deal justifies the licence, so the licence is priced against that deal, not against what it costs to store a phone number.

The pricing unit is the whole explanation

Watch what happens to the unit as you move across the three shapes. A seat product charges per person per year with an export cap, so your marginal cost of one more record is zero until you hit the cap and then it is effectively infinite. A dataset charges once for everything, so your marginal cost of one more record is zero and your marginal cost of the first record is the entire contract. An API charges per lookup, so your marginal cost is flat and your entry cost is nothing.

None of these is cheaper in the abstract. They are cheaper at different volumes, and the crossover is usually much further out than people expect. We worked the arithmetic of that crossover in Which Data API Lets You Pay Per Call Instead of a Subscription?, and the finding was that metered wins on bursty usage and loses on steady usage, which is the opposite of how most teams pick.

What the gap actually buys

To be fair to the expensive end: a seat product bundles things an API does not. Intent signals, a browser extension your reps already know, CRM writeback, a support contract, and someone contractually on the hook for compliance. If your revenue team is twelve people who live in that interface every day, none of that is overhead.

It becomes overhead the moment the consumer is a program. A pipeline does not need a browser extension, will not use the list builder, and cannot benefit from a seat. That is the situation where the per record economics stop being an abstraction: you are paying enterprise seat prices to have software call an endpoint.

Seat vs dataset vs API: what actually differs

The row that decides most cases is the last but one. A dataset is not usable by an agent until you have built the index, the matcher and the service around it, and that build is the real cost of the dataset option.

How do you enrich a company without a data subscription?

Three steps, no contract, and the first two are free. The example fills in a company record starting from nothing but a website domain.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Step 1. Find the enrichment endpoints

What it does. Searches the catalog by what you need rather than by vendor, which matters because the right provider for company firmographics is often not the right one for funding history.

The endpoints. pdl/v5/company/enrich and akta/v1/company/enrichment both take a domain and return a company record, with different strengths.

The call.

monid discover -q "enrich a company from its website domain"
monid inspect -p pdl -e /v5/company/enrich

What comes back. A ranked list with provider, billing shape and a verified flag, then the full input schema. inspect also prints the pricing note, which is where the per call versus per result distinction is stated explicitly.

What it costs. Nothing. Discovery and inspection never bill.

Step 2. Enrich from the domain

What it does. Turns one identifier into a full firmographic record.

The endpoints. pdl/v5/company/enrich, billed per call.

The call.

monid run -p pdl -e /v5/company/enrich -w -i '{"website": "brightdata.com"}'

What comes back. Running exactly that on 2026-08-25 returned display_name, size as a band, employee_count, founded, industry and industry_v2, a structured location down to postal code and geo coordinates, linkedin_url and linkedin_id, a profiles array holding every social profile the provider has matched to the company, type, a written summary, a tags array, headline, alternative_names, alternative_domains, and employee_count_by_country broken out across roughly forty countries.

Two fields matter more than the rest and almost nobody mentions them. likelihood is the provider's own confidence in the match, on a scale, which is the field you threshold on before writing anything into a CRM. And dataset_version, which came back as 35.1, is the tell this whole article turns on: see the next section.

What it costs. A few cents per call, billed per call rather than per field, so a company with forty populated fields costs the same as one with six. Current figures are on monid.ai/tools.

Step 3. Threshold, then write

What it does. Stops low confidence matches from becoming permanent records.

The call. No endpoint. A condition in whatever consumes the response:

if record.get("likelihood", 0) < 6:
    queue_for_review(record)
else:
    upsert(record)

What comes back. A review queue instead of a silent corruption. Enrichment does not fail loudly; it returns a plausible record for the wrong company, and the confidence field is the only thing standing between that and your database.

What it costs. Nothing, and it is the difference between enrichment you trust and enrichment you re-run every quarter.

The same three steps run for people rather than companies, and there is an end to end version of that in Automate Email-to-Profile Enrichment, End to End.

📖 See also Technographic Data Platforms vs One API Call: What You Give Up

Should you buy the dataset or call the API?

Here is the finding that should change how you read every vendor page in this category. That live enrichment call returned dataset_version: "35.1". The API is not looking at the live web. It is a lookup into a versioned snapshot that the provider maintains, on their refresh cadence, and hands you one row from.

Which means the dataset and the API are the same rows. The difference is not freshness in the way vendors imply. The difference is who holds the copy, and therefore who pays for the parts nobody reads.

What that actually changes

Staleness moves, it does not disappear. Buy the dataset and you own version 35.1 until you pay for 36. Call the API and the provider moves you to 36 without asking. Either way somebody is serving a snapshot; the question is whether upgrading it is your project or their release.

You stop paying for unread rows. A firmographic dataset has tens of millions of companies in it. A go to market motion touches a few thousand a year. With a dataset you paid for all of them; with an API you paid for the ones you looked up. This is the single largest cost difference and it has nothing to do with the per record price.

The compliance surface moves with the copy. Holding personal data in your own storage puts you in a different regulatory position than querying it and discarding it. That is a conversation for your counsel rather than for a blog, but it belongs in the comparison and it usually is not in the vendor's.

Only one of the two is callable at run time. An agent handed a company name can call an endpoint. It cannot query a dataset you have not yet indexed, matched and wrapped in a service. If anything in your stack picks its own tools, that build is not optional, it is the price of the dataset option.

The decision rule that falls out of this: buy the dataset when you will read most of it, call the API when you will read a slice of it. Volume is a proxy for that and a bad one. Coverage ratio is the real variable.

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-08-25. The table states billing shape rather than figures, because the shape is what changes your architecture and the figures are always current on monid.ai/tools.

Note the split between enrich and search. Enrichment is per call because you already know who you mean; search is per result because you are asking the provider to decide how many people match. Confusing the two is the most common way a prospecting budget runs away, and the fuller version of that is in our prospecting guide.

When should you buy the dataset instead?

Three cases, and they are real.

You will read most of the rows. Analytics, market sizing, model training, anything that scans rather than looks up. If your job is "how many software companies in Germany employ between fifty and two hundred people", an API is the wrong shape and no amount of per call convenience fixes it. Buy the file.

Your query pattern is not a lookup. Fuzzy matching across your whole customer base, deduplication, graph work on company relationships. These need the data local, and once it is local you have already paid the dataset cost, so you may as well have bought it properly.

Latency or volume is extreme. Millions of lookups a day against a database you control will beat any network call, and at that volume the economics have flipped anyway. Bright Data and People Data Labs both sell at that scale and both are good at it.

There is also a case for the seat product that this article has been hard on. If your buyer is a twelve person sales team who need lists, dialer integration and a browser extension today, a seat product is a better purchase than an API and a developer. The API argument only wins when the consumer is software.

And to be plain about the bias: you are reading this on Monid's blog. We sell per call access, so the case we make best is the one where you are enriching a slice rather than owning a universe. If you are going to read the whole file, buy the file.

Conclusion

There is no cheapest B2B data provider, because the three products in this category are not substitutes. Ask instead what fraction of the rows you will actually read. Read most of them and a dataset is correct and an API is expensive. Read a slice and an API is correct and a dataset is a large payment for records nobody opens.

The thing more important than that choice is the one the live response gave away: an enrichment API is a lookup into a versioned snapshot, not a window onto the live web. That reframes what you are buying from freshness to custody, and it means the honest question at every vendor meeting is not "how current is your data" but "how often do you cut a version, and what happens to mine when you do".

Free next step: run monid discover -q "enrich a company from its domain" and monid inspect the top two results. Both are free, and you will see the exact fields and the current price before spending anything. Start at monid.ai.

FAQ

Last updated August 2026.