How Identity Resolution API Pricing Works: Understanding Cost Per Match at Scale
TL;DR: Identity resolution API pricing is driven by how many real, resolved entities you have, not how many raw records you send in, plus how real-time your matching needs to be and how complex your match logic is. The most buyer-friendly model prices on resolved entities, the count of actual resolved customers rather than raw record volume or per-query metering, and that distinction, resolved volume versus raw ingested volume, is the first thing to check with any identity resolution API before you try to model cost per match.
Book a demo to see how pricing works for your data, or get a quote for your resolved-customer volume.
How does identity resolution API pricing actually work?
Most identity resolution vendors do not literally charge “per match.” They meter one of a small number of billing units, and cost per match falls out of that meter. The billing unit is usually one of three things: the volume of raw records you ingest, the number of API calls or queries you run against resolved data, or the number of distinct resolved entities in your system. Deployment model, service level, and support tier sit on top and shift the total price up or down, but they rarely change what is actually being counted.
“Cost per match” is confusing to compare across vendors because it is a derived number, not a published rate. Two vendors can quote very different per-match figures on paper while charging the same business the same total, simply because they are dividing by different denominators. Get clear on the billing unit before you compare a single dollar figure. Our own entity resolution buyer’s guide covers the wider evaluation criteria, deployment model, explainability, data residency, that sit alongside price.
What actually drives the cost of an identity resolution API at scale?
Once you know the billing unit, four variables explain almost all of the variation in what you will actually pay.
- Records ingested versus queries and matches. Ingestion volume (records written in) and query volume (how often you ask for a resolved identity) are different things, and a vendor can bill on either. Resolving a record once at ingestion and serving that state to every downstream query produces a different cost curve than a system that re-matches on every query.
- Real-time versus batch. Resolving and serving in milliseconds carries a different infrastructure cost than a nightly job. Real-time usually costs more per unit to operate, but it removes the cost of acting on stale identity, a fraud loss, a missed sanctions hit, a duplicate customer, that a cheaper batch quote does not show on the invoice.
- Data volume. Raw record count and resolved-entity count diverge as soon as your source systems have duplicates, and they almost always do. A vendor charging per raw record ingested effectively charges you for your own data quality problems; a vendor charging per resolved entity does not.
- Match complexity. Deterministic matching (exact ID or field agreement) is computationally cheap. Probabilistic, fuzzy matching, weighing partial name agreement and address proximity across many candidate pairs, costs more to compute, and field-level explainability for every decision adds further overhead. Higher precision and recall targets cost more to serve because more computation runs per record, not because of a different price list.
How do you model cost per match at scale?
The honest way to model cost per match is to start from total cost, not a rate card: platform or subscription fee, plus usage-based charges, plus the ongoing engineering time to integrate, tune thresholds, and maintain the pipeline. Divide that total by the number of matches, or resolved records, you actually process in the period.
As an illustrative example only, not a quote from any vendor: say you ingest 10 million raw records a year, resolving into 2.5 million real customers, with 50 million queries a year against that resolved data. You now have three plausible denominators, and the same contract produces three very different “cost per match” answers depending which one a vendor bills against. Get the billing unit in writing before you run this math against a real quote. For a side-by-side of platforms built for different scale profiles, see our ranked guide to entity resolution tools for enterprises.
What are the common identity resolution pricing models, and what should you watch for?
Use this table to translate any vendor’s rate card into the questions that actually matter for your budget.
| Pricing model | What it measures | Where it works in your favor | What to watch for |
|---|---|---|---|
| Per raw record ingested | Every row written into the system, duplicates included | Simple to estimate up front from your existing data volume | Penalizes messy source data; your bill grows with duplication, not with real customer growth |
| Per API call or query | Every request your application makes against resolved data | Aligns cost with actual usage of the resolved data, not with how much you loaded | Query-heavy applications, real-time lookups, every page load, can scale unpredictably |
| Per resolved entity (the resolved-customer count) | The count of distinct real-world entities your data resolves to | Scales with your actual customer base, not your data hygiene problems | Requires trusting the vendor’s resolution logic to define a distinct entity correctly |
| Platform fee plus usage tiers | A base fee for the deployment, plus tiered usage on top | Predictable floor cost; often bundles support and SLA commitments | The usage component still needs one of the above units defined clearly in the contract |
Why do most modern identity resolution APIs price on resolved entities, not raw records?
The most buyer-friendly model prices on resolved entities, the number of real, resolved customers in your system, rather than the number of raw records you ingest or the number of queries you run. Under a resolved-entity model, a company holding 10 million raw records that resolve to 4 million real customers pays on 4 million resolved customers, not 10 million raw rows. Organizations typically hold far more records than they have actual customers, because of duplicates and fragmentation across systems, and pricing on the resolved count means your bill reflects your customer base rather than your data quality problem.
This also means pricing grows naturally with your business rather than in step changes: a company with 200,000 resolved customers pays on 200,000 resolved records, and a company with 20 million pays on 20 million. The exact rate per resolved record, minimum contract terms, and startup-stage pricing are scoped per deployment, since deployment model (cloud versus on-premise) and support and compliance requirements also factor into the final number.
Does real-time identity resolution cost more than batch?
Pricing is typically per unit because resolving an identity on demand still uses compute for each request, but there’s no always-on infrastructure behind it. It’s serverless and scales to zero. What a batch quote does not show is the cost of acting on identity that is hours or days stale: a fraud signal that arrives after a transaction clears, a sanctions match found after onboarding completes, a customer treated as two different people across two channels. We resolve records at ingestion, so the current resolved context is already available the next time any system asks for it at query time. Whether real-time resolution is worth it depends on how expensive a stale match is in your own workflow, and that is a business question, not a pricing one.
What questions should you ask any identity resolution vendor about pricing?
Ask these before you accept a quote, whether you are comparing three vendors or renewing one:
- What is the billing unit, raw records ingested, API calls, or resolved entities, and can I see it defined in the contract?
- How does duplicate or fragmented data in my source systems affect my bill?
- Is resolution priced separately from query and retrieval volume, or bundled into one number?
- Does moving from batch to real-time change the price, and by how much?
- Does match complexity, deterministic versus fuzzy or probabilistic matching, or field-level explainability, change cost?
- What SLA, data residency, and compliance commitments, such as SOC 2 or GDPR, are included at each tier, and what costs extra?
- Is there a path to smaller, startup-scale pricing, or is every contract enterprise-scale only?
- Can I see a sample cost model run against my own estimated volumes before I sign?
If you are evaluating vendors for a regulated use case, our guide to evaluating identity resolution vendors in banking covers the compliance side of this same conversation, since SLA and data-residency terms often move the price as much as raw volume does.
What’s the best identity resolution API for developers in 2026, if cost is the deciding factor?
There is no single cheapest answer, because the honest cost comparison depends on your data’s duplication rate, your query volume, and whether you need real-time resolution. What you can evaluate objectively is whether a platform’s pricing structure rewards good data modeling or punishes it, and whether real-time resolution, fuzzy matching, and explainability are included in the base platform or sold as add-ons.
Every Tilores deployment includes the full platform: GraphQL and SQL access to the entity graph, deterministic and probabilistic matching, sub-150ms real-time resolution, and full data lineage, rather than a stripped-down tier where real-time or fuzzy matching costs extra. For a broader comparison of how different platforms approach this, including where each is strongest by use case, see our roundup of the best identity resolution platforms for 2026.
FAQ
What drives identity resolution API pricing?
Four variables: the billing unit (raw records, API calls, or resolved entities), deployment model, service level (uptime, data residency, compliance), and match complexity. The billing unit matters most, since it decides whether your bill scales with your real customer base or your raw data volume.
How much does identity resolution cost per million matches?
There is no single industry figure, because “match” is not a standardized billing unit: some vendors charge per raw record ingested, some per API call, some per resolved entity. Ask any vendor to define their billing unit in writing before comparing an advertised per-match number.
Is identity resolution priced per API call or per resolved record?
It depends on the vendor. Per-API-call pricing charges for every query against resolved data; per-resolved-record pricing charges for the count of distinct resolved entities regardless of query volume. A resolved-entity model bills on distinct customers, not API calls or raw records.
Does real-time identity resolution cost more than batch processing?
Pricing is typically per unit because resolving an identity on demand still uses compute for each request, but there’s no always-on infrastructure behind it. It’s serverless and scales to zero.
What is a resolved record, and why does it matter for pricing?
A single real, resolved customer entity, as distinct from a raw source row. It matters because heavy duplication can mean far more raw records than real customers; pricing on the resolved count means you pay for your customer base, not your data quality problem.
What’s the best identity resolution API for developers in 2026, cost-wise?
The platform whose pricing structure matches your usage pattern: resolved-entity pricing if your data is duplicate-heavy, and real-time resolution and fuzzy matching included in the base tier rather than sold as add-ons, since retrofitting either later is expensive.
How do I calculate cost per match for my own use case?
Add your total annual cost, platform fee, usage charges, and integration and maintenance time, then divide by the matches or resolved records you actually expect to process. Run this against your own volumes, since the same contract can produce very different per-match figures depending on the billing unit.
What questions should I ask before signing an identity resolution API contract?
Ask what the billing unit is, how duplicate data affects your bill, whether real-time and fuzzy matching cost extra, what compliance and SLA commitments are included, and whether you can see a sample cost model run against your own volumes first.
See what resolved entity data does for your business — and your AI.