Data Enrichment API Pricing: Credits vs Flat Rate vs Per-Call

Data enrichment APIs are priced three ways: credit-based (a prepaid pool, one or more credits spent per lookup), flat-rate (one price, unlimited requests), and per-call metered (a small fixed charge every request, no pool to manage). Most vendors in this category default to credits, which is also the model that hides the real cost best, because "credit" is not standardized: two vendors advertising the same headline number can cost meaningfully different amounts once you check what actually consumes one.

Credit-based: a monthly allotment of credits (typically 1,000 to 10,000 on a starter plan), one or more spent per successful match, unused credits expiring at renewal rather than rolling over. Cheapest for light, occasional usage; most expensive at volume, since the per-credit rate rarely improves without a negotiated contract.

Flat-rate: a single monthly or annual price, every endpoint included, no separate unit to track. Worse value for a handful of calls a month (paying for unused capacity), better for anything closer to continuous, since the marginal cost of one more request is zero.

Per-call metered: a fixed, small charge per request (often a fraction of a cent), no pool to manage or expire. Behaves like flat-rate at low volume and like credits at high volume, which makes it the fit for one specific case: a feature used often enough to need automation, but not often enough to justify a flat license on its own.

It depends on the vendor, and this is the single detail that most affects a real bill. Some providers only charge a credit on a confirmed match and refund it on a miss. Others charge on every attempt regardless of outcome, on the reasoning that the lookup was performed either way. A handful charge more than one credit per record when it includes certain fields, a work email or a phone number credited separately from the base profile.

The fix is the same regardless of vendor: run a real batch, a few hundred records from your own list rather than the vendor's demo dataset, and count exactly how many credits it consumed against how many records actually came back. That measured number, not the advertised price-per-credit, is what a monthly bill actually tracks, and it is usually available on a free tier or trial before any commitment.

No. A caller should only be billed for a request that reached a real data source and got a real answer back, a match or a confirmed miss, never for a request the vendor itself failed to deliver, a timeout, an upstream outage, a malformed response on their end.

On Kooperativa's metered endpoints specifically, a credit is billed on any result the live lookup actually returned and is never billed on a 5xx or a failure on our side. That line, billed on a real answer, not billed on our own failure, is worth asking any per-call or credit-based vendor about directly: it is the detail most likely to silently inflate a bill if a provider does not draw it that way.

A CRM backfill or a continuous enrichment pipeline, usage closer to constant than occasional, is what flat-rate pricing is built for: predictable cost regardless of how much the pipeline runs in a given month. A one-time list-cleaning project, a few hundred or a few thousand records with no ongoing need after, is what credits fit best, since paying for a full month of unlimited access for one afternoon of work is the wrong trade either way.

A feature only some requests need, a live re-check on a record that might be stale, a fallback when a cached lookup returns empty, is what per-call metering fits: occasional, not constant, not worth a flat commitment on its own. That is the model behind Kooperativa's two realtime endpoints: the $499/mo flat license covers every standard lookup unmetered, and only the live re-fetch path is billed per call, at $0.001 each.