B2B Data Enrichment API: Test Match Rate First
By Kooperativa Engineering
Every B2B data enrichment vendor advertises a match rate somewhere on their pricing page, usually a number between 85 and 98 percent. Almost none of them explain what denominator that percentage is measured against, and the denominator is the whole story.
A vendor can report a 95 percent match rate by testing against a list of Fortune 500 executives, a population that is well documented everywhere, and the same vendor might resolve 40 percent of a list of mid-market operations managers in Eastern Europe. Both numbers are true. Only one of them describes what you will actually get.
The test that actually tells you something
Pull 50 to 100 records from your own CRM or your own target list, ones where you already know the correct current title and employer by hand. Run those through the API you are evaluating. Count how many came back with the right employer, not just any result, the right one.
This takes about twenty minutes and it is the only match rate number that means anything for your specific use case, because it is measured against the population you actually care about, not a vendor-chosen sample.
What a real bulk response looks like
Once you have a batch of identifiers, most enrichment APIs return one of three outcomes per record rather than a flat "found or not found." Ours looks like this on a batch of two identifiers:
{
"profiles": [
{
"id": "f9413465-...",
"full_name": "Satya Nadella",
"current_title": "Chairman and CEO",
"current_company": "Microsoft",
"fetched_at": "2026-06-21T17:44:00Z"
}
],
"matched": 1,
"requested": 2,
"not_found": 1,
"failed": 0
}Why "not_found" and "failed" being separate matters
If a provider only returns matched versus unmatched, a transient timeout on their end gets counted the same as a record that genuinely does not exist in their dataset. That difference matters a lot when you are deciding whether to retry an identifier or drop it permanently. A response that separates the two, matched, not_found, failed, is a small signal that the vendor has actually operated this at scale and hit that exact bug before.
A checklist for the rest of the evaluation
Match rate against your own sample is the first thing to check, not the only thing.
- Freshness: ask when the specific records you tested were last refreshed, not the dataset average.
- Response time at the 95th percentile, not the average, since averages hide the slow requests that actually cause timeouts in production.
- Whether pricing is per credit or a flat rate, and what happens to your workflow if usage doubles overnight.
- Whether the provider documents field-level null behavior, or you find out by hitting it in production.
Get started
Try Kooperativa
One API key. Person and company enrichment, structured search, and monitors under one flat license.