A B2B data API is an endpoint that returns structured information about companies and the people who work at them. You send an identifier, it sends back the facts attached to it.
That’s the definition. But it doesn’t tell you which one you need, and there are at least four different things people mean when they say “B2B data API.” So let’s sort that out first, because picking the wrong category is the expensive mistake here.
I’ve made that mistake personally. I’ll tell you about it further down; it involved 12,000 CRM rows and a vendor who didn’t deserve the blame we gave them.
What does a B2B data API actually return?
It depends entirely on what you send it. And that’s the mental model I’d hold onto: these APIs are keyed by input, not by output.
| You send | You get | Typical use |
|---|---|---|
| Company name or domain | Industry, revenue, headcount, location, tech stack | Lead scoring, territory routing |
| Email address | The person and their company | Form enrichment, CRM cleanup |
| Name + company | Job title, seniority, contact details | Outbound targeting |
| Filters, not an identifier | A list of matching companies or people | Building a prospect list from scratch |
That last row is the one people miss. Enrichment completes a record you already have. Search creates records you don’t. They’re different products even when the same vendor sells both, which is why our own docs split the company search endpoint from the enrichment ones entirely. The confusion is expensive in both directions: teams buy enrichment credits and then wonder why they can’t “get a list of fintech companies in Texas,” or buy search access to fix records they already had identifiers for.
What do the returned fields actually look like? For a company: legal and trading names, domain, industry classification, employee count and band, revenue estimate, founding year, headquarters and office locations, social profiles, and often technographic and funding detail. For a person: name, current title, seniority, department, company affiliation, work email, sometimes phone and profile links.
All of it arrives as structured JSON your systems can consume directly. That’s the entire pitch, honestly: facts your team would have researched by hand, returned in milliseconds in a machine-readable shape.
The four categories of B2B data API
Four categories cover nearly everything sold under this label. Most teams eventually run two of them.
Firmographic APIs return company facts. Size, industry, revenue, location, founding year: the demographic profile of a business. This is the workhorse category and where most teams start, because company-level data both decays slowest and drives the most decisions: scoring, routing, segmentation, TAM sizing. If you’re only going to buy one category this quarter, it’s almost certainly this one; every other data type gets more useful once the company layer underneath it is solid.
Contact APIs return people. Job titles, seniority, verified emails, phone numbers, profile links. Higher value per record and higher decay, because people change jobs constantly: a contact record is a snapshot of an employment relationship, and employment relationships end. Budget for that decay from day one: the contact list you buy in January is measurably staler by summer, whoever sold it to you.
Technographic APIs return the software a company runs. Narrow, but if you sell an integration, a migration, or anything stack-dependent, it’s the single most useful signal you can buy. I’ve gone deeper on this category in our technographic data API guide.
Signal APIs return events rather than attributes. Funding rounds, hiring surges, leadership changes, expansion moves. These tell you when to act rather than who to act on: timing data layered over the other three categories. A concrete example: a company that just raised a round and posted five sales openings is telling you its budget cycle out loud. Signal APIs turn that into a webhook instead of a lucky LinkedIn sighting.
📌 Most teams need two. A firmographic API to qualify accounts, and a contact API to reach someone inside them. Adding a third before those two work is usually premature.
The fields that matter (and the ones that don’t)
Not all returned fields are equal, and vendors rarely advertise the difference. Three properties decide a field’s real value:
Fill rate: how often the field comes back populated at all. Accuracy: how often the populated value is right. Decay speed: how fast a right value goes stale. A field can have a 95% fill rate and mediocre accuracy; another can be accurate but present on a third of records. Ask about all three, per field, not per database.
| Field | Decay speed | What to know |
|---|---|---|
| Domain, founding year, HQ country | Very slow | Nearly permanent once right; cache aggressively |
| Industry, company size band | Slow | Changes with real company events; annual refresh is fine |
| Revenue estimate, tech stack | Medium | Estimates and detections, not registry facts; treat as directional |
| Job title, seniority | Fast | Tied to one employment relationship; verify before big sends |
| Work email, direct phone | Fastest | The most valuable and most perishable fields in the record |
The practical takeaway: build your refresh schedule per ROW of that table, not per database. Re-verifying founding years monthly is wasted spend; trusting eight-month-old direct dials is wasted outreach. Match the cadence to the decay.
And be appropriately skeptical of the estimate-shaped fields. Revenue figures for private companies are modeled, not reported. Good vendors say so. Use them for banding and segmentation, never as facts in a pitch; nothing torpedoes credibility like quoting a company’s “revenue” back to them wrongly.
One distinction worth pinning down before we go further, because two industries share the phrase “B2B API.” A B2B data API ships information INTO your stack: facts about companies and people. An integration API (the iPaaS world) moves records BETWEEN tools you already use. If you’re researching connectors between your CRM and your billing system, that’s the other meaning, and this article won’t help you. Everything below is about the data kind.
So that’s the data. Here’s the machinery behind it.
How B2B data APIs work under the hood
Every provider runs the same three-stage machine: collect, resolve, serve. The differences that matter to you live in stages one and two.
Collection. The data comes from some blend of public web sources (company sites, registries, job boards, news), licensed partnerships, and contributed data: networks where users share their address books or CRM signals in exchange for access. Every source has a character: registry data is accurate but slow-moving, web data is fresh but messy, contributed data is rich but uneven. Ask any vendor you evaluate where THEIR blend leans; the good ones answer specifically.
Three sourcing questions worth asking in every evaluation call: Which fields come from which source type? How is contributed data validated before it enters the database? And what happens when two sources disagree about the same company? The answers reveal more about eventual data quality than any accuracy percentage on a homepage; vendors who can walk you through their disagreement-resolution logic are vendors who actually have one.
Entity resolution. This is the invisible step that decides your match rate. Entity resolution means deciding that “ACME Corp,” “Acme Corporation,” and “acme.com” are the same company, and that the Jane Doe at Acme in one source is the Jane Doe who moved to Initech in another. When a lookup fails, it usually fails here: not because the data doesn’t exist, but because your input didn’t resolve to the right entity.
Serving. The resolved records sit in an indexed database behind REST endpoints, refreshed on some cycle: continuous for the best fields, weekly or monthly for others. This is why freshness timestamps per field are worth asking about. A provider that can tell you when each attribute was last verified is telling you they track it. A provider that can’t is telling you something too.
Why does match rate deserve this much attention? Because it’s the honest metric in a market full of database-size claims. “300 million profiles” tells you nothing about whether YOUR 5,000 accounts are in there. The percentage of your own list that comes back enriched: that’s the number your project lives or dies on.
Real-time, batch, and waterfall: the three implementation patterns
Same endpoints, three very different ways to consume them. Pick deliberately, because the pattern shapes your costs and your architecture.
Real-time enrichment
The API gets called the moment a record appears: a form submit, a signup, a new CRM row. The record enters your systems already complete, and downstream automation (scoring, routing, alerts) fires on real data immediately.
The constraint is latency. If enrichment sits inside a user-facing flow, a slow call is a slow page. Benchmark response times under real traffic, decide what happens on a timeout, and never let a data lookup block a signup. Enrich asynchronously a few seconds later if you can; the scoring model won’t notice the difference, and your conversion rate will thank you.
Batch enrichment
Nightly or weekly jobs that sweep through records in bulk: the pattern for cleanups, migrations, and scheduled refreshes. The arithmetic is rate limits. At a documented fixed window of 100 requests per minute (the limit on our own company enrichment endpoint, for instance), a batch job moves 6,000 records an hour. A 50,000-row cleanup is an overnight job, not a coffee-break one. Plan the schedule around the math, add retries with backoff for the inevitable hiccups, and checkpoint progress so a failure at row 40,000 doesn’t restart at row one.
Waterfall enrichment
Waterfall enrichment means trying providers in sequence: query the first, and only send the misses to the second, then the third. Because coverage differs by geography and segment, two providers in a waterfall reliably beat either one alone on total match rate.
The trade-offs: two contracts, two compliance reviews, a merge policy for when providers disagree, and more pipeline to maintain. My honest rule of thumb: get your inputs clean and your first provider well-chosen before adding a second. A waterfall built on unnormalized data just distributes the same misses across more invoices.
What people actually build with one
The use cases repeat across almost every team I’ve worked with:
- CRM autofill and cleanup. New record arrives with just an email; the API fills in company, size, industry, title. Existing records get re-verified on a schedule instead of rotting quietly.
- Lead scoring and routing. Headcount and industry arrive at form-submit time, so the scoring model runs on facts instead of self-reported fields, and the right rep gets the lead while it’s warm.
- Form shortening. Ask for the email only, enrich the rest behind the scenes. Shorter forms convert better; the data arrives anyway.
- Prospect-list building. Search endpoints turn an ICP definition into an account list. I’ve written the full workflow up separately: build a prospect list with a company data API.
- Account-based targeting. Enrich the target-account list once, segment by real firmographics, and stop advertising to companies that were never in your market.
- Product features. Some teams don’t consume the data internally at all; they build it into their own product: company lookups in a fintech onboarding flow, employer detail in an HR tool, risk signals in a lending model.
A quick sketch of how these compound. A team shortens its demo-request form to two fields and enriches on submit: the form converts better because it asks less, the scoring model gets MORE data than the long form ever collected, routing fires on real firmographics within seconds, and the rep opens the call knowing the company’s size, stack, and industry. Four improvements, one API call, no human in the loop. That’s the compounding logic that makes enrichment sticky once it’s wired in properly.
Different builds, same pattern: an identifier your system already holds, exchanged for facts your workflow needs at exactly the moment it needs them.
Marketing pages won’t tell you which category you need, though. Your identifiers will.
How to choose one
Work backwards from the identifier you already hold. Everything else follows from that.
- Domains. The luckiest position: domains are unambiguous, so any firmographic API will match well. Go straight to enrichment.
- Company names only. Resolve them to domains first with a name-to-domain endpoint, or your match rates will be poor for reasons that have nothing to do with the provider. Names are ambiguous; domains aren’t.
- Email addresses. A reverse-lookup endpoint gives you person and company in one call; the email’s domain anchors the company match.
- Nothing yet. Then you need search, not enrichment. Different endpoint, different pricing model, different evaluation.
And then judge providers on four things, in this order:
Match rate on your own list. Not the number on their homepage. Every provider quotes a match rate against an idealized dataset, and yours is messier than that. Two hundred real records through a free tier settles it in an afternoon.
Freshness. Ask when each field was last verified. Good providers timestamp every attribute. The ones that change the subject are telling you something.
Geographic coverage. Almost everyone is strongest in North America. If you sell into Europe or Asia, test there specifically or you’ll be disappointed after signing, not before.
Cost per usable record. Not cost per call. A provider at half the price with a 40% match rate is more expensive than one at 80%, and that arithmetic reorders most shortlists.
The 30-minute technical evaluation
Beyond the data itself, half an hour with a vendor’s documentation answers most integration questions before you write a line of code:
- Can you read the docs without logging in? Public documentation is a confidence signal. Docs behind a sales wall usually mean access is too.
- What does a miss look like? A clean 404, a 200 with an empty body, or a partial record? Your error handling, and your billing, depends on the answer.
- Are rate limits documented as numbers? “Contact us for limits” makes batch planning guesswork.
- Do responses include confidence or freshness metadata? Field-level timestamps let you build refresh logic instead of guessing.
- Is there an SDK for your language, and is it maintained? A stale SDK means you’ll be writing raw HTTP calls anyway. Fine, but know it going in.
- How are errors and partial failures billed? Timeouts, malformed inputs, ambiguous matches: each vendor treats them differently, and the treatment belongs in your cost model.
None of this replaces the 200-record test. It just tells you which vendors deserve one.
🔍 The formula: cost per usable record = total spend ÷ records you can actually act on. → sticker price → adjust for YOUR match rate → adjust for whether misses cost credits → compare. Run it on every candidate before believing any pricing page.
On pricing models themselves: you’ll meet credit plans, subscriptions, pay-as-you-go, and enterprise quotes. The fine print that matters most is whether failed lookups cost you. Some vendors document this precisely: People Data Labs’ pricing documentation states it in one line:
“Credits are consumed per successful match from the API.”
People Data Labs, Pricing & Credits documentation
Hits cost, misses don’t. Whatever vendor you pick, get their version of that sentence in writing; a 60% match rate doubles your effective price if the other 40% still burns credits.
What free tiers are for (and what they’re not)
Free tiers exist to answer one question: does this vendor’s data cover MY market? A few hundred free credits are exactly enough to run the 200-record test, hand-check a sample, and compute your real numbers. That’s their job, and they do it well.
What they’re not: a production plan. Teams occasionally architect around staying under a free cap: rotating keys, throttling real workflows to fit. It’s a false economy twice over: the engineering time costs more than the entry-tier subscription, and it usually violates the vendor’s terms anyway. Use the free tier to decide. Then either pay or walk, but decide.
Build vs buy: when a data API earns its place
Could you scrape and assemble this data yourself? Technically, often yes. Should you? Run the honest math.
Building means: crawlers for every source, parsers that break when sites change, an entity-resolution layer (the genuinely hard part), a refresh pipeline so the data doesn’t rot, and compliance review for every source you touch. That’s not a weekend project; it’s an ongoing engineering commitment with a permanent maintenance tail. Teams that build it well are usually teams whose PRODUCT is the data.
Buying means: someone else amortizes all of that across thousands of customers, and you pay per record or per month. For standard firmographic and contact data, the buy side wins for almost everyone; the fields are commoditized and the vendors compete on exactly the maintenance you’d otherwise own.
Put rough numbers on it. A build is at minimum one engineer part-time, forever: call it a five-figure annual cost before infrastructure. Documented self-serve pricing for the same commodity fields starts around $49-98 a month at the entry tiers. The build has to be delivering something the bought data can’t before that gap closes. Usually it isn’t.
Build wins in one situation: when you need unusual fields no vendor tracks: niche-industry attributes, hyper-specific signals, data only visible in sources nobody else parses. Then a small, focused pipeline for THAT data, layered on top of a bought foundation for the standard fields, is the pattern that works. Build the rare thing. Buy the commodity.
What a call actually looks like
Most B2B data APIs are boring REST endpoints, which is exactly what you want. Here’s the shape:
from cufinder import Cufinder
client = Cufinder('your-api-key-here')
# firmographic: domain in, company facts out
company = client.enc('stripe.com')
# contact: name + company in, person record out
person = client.tep('jane doe', 'stripe')One call, one record. Batch it in a loop with a pause for rate limits (ours is a documented fixed window of 100 requests per minute) and you have a pipeline.
The company enrichment and person enrichment references have the full request and response shapes, plus SDK examples in a few languages. Disclosure where it’s due: that’s our own API in the example (it’s the one whose SDK I can quote accurately) but every principle on this page applies to whichever vendor your 200-record test picks.
Whatever the vendor, teach your code three response cases before shipping: a clean match (use it), a miss (log it, don’t retry it forever; a company genuinely absent today is usually absent tomorrow too), and a partial or low-confidence match (route it to review instead of silently trusting it). Pipelines that only handle the happy path generate the data-quality complaints that get blamed on vendors six months later.
Wiring it into your stack
An enrichment call is easy. An enrichment SYSTEM has a few more moving parts, and thinking about them upfront saves rework:
Where the call lives. Three common homes: inside your application code (most control, most maintenance), in middleware or an automation platform between your forms and your CRM (fastest to ship), or as a scheduled job against your warehouse with the results synced back (best for bulk hygiene). Most mature setups end up with two of the three: real-time for new records, scheduled for refresh.
Caching and idempotency. Don’t pay twice for the same fact. Cache responses keyed by identifier, set a sensible expiry per field type (company facts age slower than contact facts) and make your pipeline idempotent so a retried job doesn’t re-bill the same rows. Some vendors handle the repeat-lookup case for you; ours doesn’t charge repeated lookups of the same record, and whichever vendor you pick, ask how they treat it.
Field mapping and ownership. Decide which system owns each enriched field, and whether enrichment can overwrite human-entered values. The classic quiet failure: a rep corrects a company’s segment by hand, the nightly job overwrites it, and trust in the whole dataset erodes. A simple rule (enrichment fills blanks, humans win conflicts) prevents most of it.
Monitoring. Log match rate per job, latency, and credit consumption. A sudden match-rate drop usually means an input-format regression on your side, not a vendor outage, and you want the alert before the quarter’s credits are gone either way.
The provider landscape
Who actually sells this stuff? Six shapes cover the market. This isn’t a ranking; it’s a map, and the honest method note is that every fact below comes from the vendors’ public documentation, checked August 2026.
| Provider | Shape | Access | Pricing status |
|---|---|---|---|
| CUFinder | Self-serve enrichment + search, company and contact | Instant key, free credits | Published credit plans |
| People Data Labs | Raw person + company records at developer scale | Self-serve | Documented, from $98/mo |
| ZoomInfo | Enterprise NA depth + intent layers | Sales-led, annual contracts | Quote only |
| Coresignal | Bulk datasets + database APIs for warehouses | Self-serve + contracts | Partial, from $49/mo |
| Apollo.io | Data bundled with outreach tooling | Free plan, per-seat | Published seat plans |
| Dropcontact | European contact enrichment, GDPR-first | Self-serve | Published, pay-on-success |
The documented anchors, linked as promised: People Data Labs publishes full credit tables in its pricing documentation with Pro plans from $98 per month, and Coresignal’s pricing page documents a free plan with monthly plans from $49. ZoomInfo publishes no API pricing (enterprise quotes only) and its API documentation sits behind a sales-led access process. The rest publish structures I’d summarize rather than numbers I can anchor.
No winner declared, deliberately. CUFinder is ours; judge it with the same 200-record test you’d give anyone else. The category strengths are real: enterprise depth lives at the top of the market, developer economics live in self-serve, European compliance lives with the specialists. Your identifiers, geography, and volume pick the provider. The comparison threads on r/AI_Agents asking for the best B2B data APIs right now are worth skimming for exactly this reason: every recommendation there comes with a different use case attached.
Shortlisting from the map
Turn the table into a shortlist with three filters, in order:
- Access filter: if you need to test this week, the sales-led rows drop out immediately; whatever their data depth, you can’t measure it yet.
- Shape filter: record-by-record enrichment and bulk datasets are different products. Pick the shape that matches your architecture, not the vendor with the best-known name.
- Geography filter: if a meaningful slice of your market is outside North America, that requirement eliminates more candidates than any feature comparison will.
Two or three names survive the filters for most teams. Those get the 200-record test. The map’s job is done.
A worked example: from messy export to enriched CRM
Let’s make the whole pipeline concrete with round illustration numbers; the shape is what matters, not the specific figures.
You start with a 12,000-row CRM export of company names collected over five years by four different teams. The pipeline:
- Normalize. Trim whitespace, standardize casing, strip or standardize legal suffixes (Inc, Ltd, GmbH). Cheap string work, no API needed yet.
- Deduplicate. Exact and fuzzy matching on the normalized names. In my experience a multi-team CRM export loses 15-20% of its rows here: call it 12,000 down to 9,800 unique companies. That’s 2,200 lookups you now won’t pay for.
- Resolve names to domains. Run the 9,800 names through a name-to-domain endpoint. Domains are unambiguous keys; names aren’t. Whatever fails here goes to a manual-review file, not into the enrichment queue.
- Enrich. Send the resolved domains for firmographics, batched under the rate limit: at 100 requests a minute, roughly a day of unattended processing including retries.
- Import with rules. Enrichment fills blanks; human-entered values win conflicts. Log the per-batch match rate as your baseline for next quarter’s refresh.
→ 12,000 raw rows → 9,800 unique → domains resolved → enriched and scored → a CRM your reps stop apologizing for. The API is one step of five. The other four are why two teams with the same vendor get completely different results.
Where B2B data API projects go wrong
I’ve watched the same four mistakes repeatedly, and none of them are the provider’s fault.
Enriching dirty data. This one’s mine, so let me tell it properly. Hamburg, 2019, my first serious enrichment project: a 12,000-row CRM export, straight into a vendor’s API, and a match rate that looked embarrassing. We blamed the API. Then someone actually READ the export: trailing spaces, “GmbH” suffixes in half the German rows and not the other half, three different spellings of the same parent company. We normalized the names, deduplicated, resolved names to domains, and re-ran. Most of the “missing” matches appeared, and the deduplication alone meant we’d been about to pay for roughly a fifth more lookups than we had unique companies. The vendor was never the problem. Our inputs were.
💡 The order matters: normalize first, deduplicate second, enrich third. Every step you skip on the left gets billed to you on the right: in credits, in missed matches, or in both.
Enriching everything. Appending forty fields you never filter on burns credits and clutters your schema. Decide which attributes you’ll actually score or segment on, and pull only those. You can always widen later; you can’t un-spend the credits.
Treating it as a one-time project. B2B data decays continuously (people change jobs, companies move, rebrand, and merge), so a single enrichment pass is a snapshot that starts aging immediately. Contact fields age fastest of all. Enrich on write, or re-enrich on a schedule. Ideally both.
Ignoring compliance. Contact data about real people carries legal obligations: GDPR in Europe and the CCPA in California are the two your review will start with. Ask every vendor about their lawful basis, their deletion handling, and where the data is processed, before your legal team asks you. A data project that clears compliance late clears it expensively. And keep your own house in order too: enriched contact data in your CRM makes YOU a data controller, with obligations no vendor contract transfers away.
Frequently asked questions
What is a B2B data API?
An endpoint that returns structured company or contact information when you send it an identifier such as a domain, an email, or a company name. It replaces manual research with a programmatic call that returns JSON in milliseconds.
Is a B2B data API the same as an enrichment API?
Enrichment is one function of it: the identifier-in, record-out call. “B2B data API” is the wider umbrella that also covers search, technographic, and signal endpoints. Most vendors sell several of these behind one key, which is why the category name blurs.
What’s the difference between enrichment and search?
Enrichment completes a record you already have. Search finds records you don’t. Got a list? You want enrichment. Got criteria instead? That’s search: different endpoint, and usually a different pricing meter too.
How accurate is B2B data API data?
It varies by field and geography. Company-level attributes are generally more reliable than contact-level ones, and North American coverage beats everywhere else for most vendors. Test on your own records in your own market rather than trusting a headline figure; accuracy claims are always measured on the vendor’s terms.
Is there a free B2B data API?
Several providers offer free tiers with limited monthly credits, enough to test match rates on a real sample, which is their genuine purpose. CUFinder starts you with free credits, and People Data Labs documents a free plan on its pricing page. Enterprise-only vendors typically require a contract before you can call anything.
Can I use a B2B data API with Python?
Yes. Python is the default language of this category. Most providers ship a Python SDK or a plain REST interface that works with any HTTP client; the code block above is a complete working example. A loop, a rate-limit pause, and a CSV writer are genuinely all a first pipeline needs.
How much does a B2B data API cost?
The range runs from free testing tiers to enterprise annual contracts, with self-serve credit plans in between: documented examples include People Data Labs from $98 per month per its pricing documentation and Coresignal’s monthly plans from $49 per its pricing page. Because match rates vary, compare on cost per usable record from your own test rather than sticker price.
What is waterfall enrichment?
Querying multiple providers in sequence, sending each provider only the records the previous ones missed. It raises total match rate because coverage differs by vendor, at the cost of extra contracts, compliance reviews, and merge logic. Worth it at scale, premature before your first provider and your inputs are working well.
What’s the difference between a B2B data API and buying a database export?
An export is a snapshot; an API is a connection. A purchased CSV starts decaying the day it lands and can’t answer questions about records it doesn’t contain. An API returns the current version of any record on demand and scales with your actual usage. Exports still make sense for one-off analysis; for anything operational, the connection beats the snapshot.
How often should I re-enrich?
Quarterly suits most teams. Monthly if you run high-volume outbound, since contact data decays fastest. Better still, enrich on write so records enter your database complete, then reserve scheduled re-enrichment for the segments your revenue actually depends on.
Where to start
Take 200 real records, pick two providers with free tiers, and run the same list through both. Count what matched, hand-check twenty, and work out the cost per usable record.
→ Identify your identifier → normalize and dedupe → test two vendors on 200 rows → compute cost per usable record → wire the winner in with caching and a refresh schedule. Five steps. The first two are free, and they’re the ones most projects skip.
That afternoon of work will tell you more than any comparison table, including the one on this page. And the rows that fail will teach you something about your own data that you probably didn’t want to know but genuinely needed to.
Start with the category, not the vendor. Firmographic or contact, enrichment or search, real-time or batch: those three choices, made from your own identifiers and workflows, do more for the outcome than any brand name on the invoice.
Mine taught me about the GmbH problem, one embarrassing match-rate report at a time. What will yours teach you? Run the test this week and find out; the free tiers make it a zero-budget experiment, and the worst case is an afternoon spent learning your CRM’s real condition. If the answer surprises you, I’d honestly like to hear which way it surprised you.
Bad
Okay
Good
Amazing
