An identity resolution API answers one question at scale: do these two records describe the same person or company? Getting that answer right is what separates a database your team acts on from one they work around.
This guide covers how these APIs work, what to look for before you buy, why implementations underdeliver, and where B2B identity resolution parts ways with the consumer version, with a focus on go-to-market teams.
What an identity resolution API does
An identity resolution API is an endpoint that takes fragmented or partial data about a person or company, matches it against a unified identity graph, and returns one resolved record with a persistent identifier. It works out which scattered inputs point to the same real-world entity, then hands back a single record you can build on.
The mechanism underneath is the identity graph, a continuously maintained map of which identifiers belong to which real-world entity. You send the API a fragment, it locates the matching entity in the graph, and it returns that entity as a single resolved record. Because the identifier it returns is persistent, you can attach it to your CRM record and re-query it later without starting the resolution over.
What separates this from a simple lookup table is that a resolution engine weighs incomplete and conflicting inputs to decide which entity a fragment belongs to, then returns a match it stands behind rather than a raw list of possibilities. That judgment is what lets you automate the steps that follow.
The matching methods behind identity resolution
Resolution engines rely on three techniques, and the interesting decisions live in how they are combined. Understanding the tradeoffs helps you predict where an API will match well and where it will quietly produce false positives.
Deterministic matching links records on exact, high-signal fields such as a verified email, a logged-in account ID, or a unique company identifier. When clean identifiers exist it is dependable, because two records either share the field or they do not. Its weakness is coverage: incomplete or mistyped inputs slip through.
Probabilistic matching applies machine learning to estimate the likelihood that two records describe the same entity, weighing similar names, shared locations, and overlapping attributes. It extends reach into the fragments deterministic logic misses, at the cost of introducing matches you need to tune and validate.
Anonymous stitching captures behavior before a record is identified, then folds that history into a profile once the person reveals themselves through a login or form submission. It matters more for web and product analytics than for record-level GTM data.
Production engines blend deterministic and probabilistic logic rather than choosing one, using exact fields first and falling back to scored matches for the rest. What you want to understand before committing is how a given engine handles the uncertain middle, where a match is likely but unproven, since that is where data quality is won or lost.
How resolution moves from a fragment to a finished record
Under the hood, a resolution request travels a short pipeline from raw input to an enriched profile. Knowing the stages helps you design workflows that stay fast and cost-efficient instead of hammering the API for detail you do not need yet.
Stage | Input | What happens | Output |
Ingest | Email, phone, name, company, device ID | The API normalizes the incoming fragment | Clean query |
Match | Clean query | Deterministic and probabilistic matching against the graph | Candidate entity |
Resolve | Candidate entity | Match evaluation and merge into one record | Persistent ID |
Enrich | Persistent ID | Full attribute retrieval | Complete verified profile |
The operational lesson buried in that table is to separate discovery from enrichment. Search or match endpoints tell you who a record is and return enough to rank and prioritize. Enrichment endpoints pull the full profile and usually carry a cost. A disciplined workflow resolves broadly, confirms the right records, and enriches only what it will genuinely use. When your inputs are natural-language filters rather than clean identifiers, resolve those filters to IDs first, then match on the IDs, because names are ambiguous and IDs are not.
What to evaluate before you commit
Two resolution APIs can look identical on a feature list and behave very differently against your data. The criteria below are the ones that decide whether an implementation delivers, and most of them cannot be judged from a spec sheet alone.
Match rate on your own records. Coverage claims made against a vendor's sample data tell you little about how the graph performs on your segment, your regions, and your title mix. Run a test batch of your real records through a trial before you sign, because the match rate you get is what caps the value.
Real-time versus batch latency. Real-time endpoints resolve a record in milliseconds for live routing and personalization, while batch jobs process large volumes at a lower cost per record. Know which one each of your use cases needs, since paying for real-time on a nightly backfill wastes money and running batch on a form fill misses the moment.
Pricing model. Providers generally bill on ingestion volume, charging per record imported, or on query volume, charging when you retrieve a resolved entity. The right model depends on whether you resolve a large database occasionally or query a smaller set constantly.
Privacy and data handling. Check where records are processed and how identifiers are treated, especially if you operate under regional data quality and privacy rules. The controls a provider offers here shape both your compliance exposure and how the data can move through your stack.
The recurring theme is to test against your own data rather than the demo set. A resolution engine is only as good as its coverage of the specific people and companies you sell to.
Consumer versus B2B identity resolution
The phrase carries two distinct meanings, and picking the wrong one wastes budget on capabilities you will never use. The split comes down to what you are resolving and against what kind of graph.
| Consumer identity resolution | B2B identity resolution |
Primary goal | Unify one person across devices and channels | Resolve partial records to verified accounts and contacts |
Typical inputs | Cookies, device IDs, anonymous web behavior | Names, emails, company names, job titles |
Dominant method | Probabilistic scoring and anonymous stitching | Deterministic matching against a verified business graph |
Common owners | Adtech, ecommerce, media, product analytics | Sales, marketing operations, RevOps |
End use | Cross-channel targeting and personalization | CRM enrichment, lead-to-account matching, routing |
If your work involves connecting anonymous site visitors to consumer profiles for advertising, you want a consumer identity graph. If your work involves turning incomplete leads into clean records tied to real companies and buyers, you want B2B identity resolution built on verified firmographic data and contact data. The engines look similar on a spec sheet and solve different problems in practice.
Where identity resolution fits in a GTM stack
Resolution is worth placing in two spots, and the two have different latency and cost profiles. Deciding where you need it shapes which authentication model and which endpoints you build against.
The first placement is at the point of capture. When a lead fills out a web form or enters your funnel, a real-time API call resolves and enriches the record inline, so routing, scoring, and personalization fire against a complete profile within the same session. Speed matters here, and requests often act on behalf of a signed-in user, which suits a user-based authorization flow.
The second placement is scheduled backfill. Your existing database decays continuously as people change jobs and companies update, so a recurring batch job re-resolves and re-enriches records to keep them current and to collapse duplicates that accumulate over time. These jobs run server-to-server without a user present, which fits a client-credentials flow, and they benefit from batching and off-peak scheduling to stay inside rate limits.
Most teams end up needing both: real-time resolution to keep new records clean on arrival, and batch resolution to stop the existing database from rotting.
Common B2B use cases
Once resolution is in place, the same capability powers several workflows that RevOps and marketing operations teams run constantly. The unifying thread is that each one depends on trusting that a record points to the right entity before anything else happens.
CRM deduplication and hygiene: collapse duplicate contacts and accounts into one record before they distort reporting, lead routing, and attribution.
Lead-to-account matching: connect an inbound lead to its parent account so it reaches the correct owner and territory.
Form and signup enrichment: expand a short web form submission into a full contact and company profile in real time, so lead qualification runs on complete data.
Record refresh against data decay: re-resolve and re-enrich on a schedule as roles and firmographics change, holding accuracy steady instead of watching it erode.
Audience building: resolve and enrich at scale to assemble targeted segments for outreach, advertising, and account-based programs.
Why identity resolution projects underdeliver
Plenty of teams buy a resolution API and still end up with a messy database. The failures are predictable, and every one is avoidable with a bit of discipline up front.
Coverage assumed, not tested. A graph that resolves 90% of one vendor's sample data might resolve 60% of yours. Run a match-rate test against your own records before you commit, since coverage on your ideal customer profile is what determines the outcome.
Probabilistic matches treated as verified. Auto-writing every scored match back to the CRM propagates false positives. Hold lower-confidence matches for review instead of pushing them straight into automated write-back.
Decay ignored after go-live. Resolution is not a one-time cleanup. Without a refresh cadence, the freshly resolved database starts aging the day it is finished, a core driver of poor data quality.
Enrichment loops that burn credits. Enriching every record you touch, rather than only the ones you activate, drives cost with no return. Let search and match results do the ranking, and reserve enrichment for records headed to activation.
Resolved IDs thrown away. Re-resolving the same record repeatedly wastes calls and quota. Cache the persistent IDs you get back and re-query them directly.
How ZoomInfo resolves B2B identity through its API
ZoomInfo approaches B2B identity resolution as a match-and-enrich problem. You send a partial record, ZoomInfo matches it against a database of 100M+ companies and 600M+ professionals, and enrichment returns the full verified profile tied to a stable ZoomInfo ID.
In practice, that means:
Search before enrichment. Search endpoints find and rank candidate records, and enrichment endpoints return the complete profile, including firmographics, contact details, technologies, and organizational data, so you spend credits only where you need full detail.
Batch enrichment for scale. Enrich Company and Enrich Contact calls process up to 25 records each and bill one bulk credit per new record retrieved, which keeps large refresh jobs predictable and easy to budget.
Authentication matched to placement. Use the client-credentials flow for scheduled syncs and backend jobs, and the authorization-code flow with PKCE when requests act on behalf of a signed-in user.
Access on your terms. The same match and enrichment capabilities are available through the REST API, the ZoomInfo MCP server for AI agents and MCP-compatible clients, and the ZoomInfo CLI for command-line and agent-ready workflows.
The ZoomInfo GTM CLI runs the same match and enrich calls from the terminal or a scheduled job, over the same credits and entitlements as the API and MCP server.
The payoff is that the same partial record you started with becomes a complete, verified profile your team can route, score, and act on, tied to an ID stable enough to keep current as the underlying data changes. Whether you reach it through the API, an MCP client, or the CLI, the resolution and enrichment behavior is the same, so you can build the workflow that fits how your team already works.
Start resolving B2B identity with ZoomInfo
Identity resolution earns its place the moment a resolved record reaches the right owner, a duplicate collapses before it distorts a report, or a thin form fill turns into a complete, routable profile. For B2B go-to-market, that comes down to matching partial records to verified companies and contacts and keeping them current as buying signals and the market move.
ZoomInfo does exactly that against a database of 100M+ companies and 600M+ professionals, reachable through the API, the MCP server, or the CLI. You can start before building a full OAuth flow:
Create an application from the Developer tab in GTM.ai, or from the Developer Portal if you are an enterprise customer
Generate a token with Test API Access and paste it into the API Reference
Run your first search or enrich request and watch a partial record resolve into a full profile ready to sync to your CRM
Frequently asked questions
What is the difference between identity resolution and data enrichment?
Identity resolution determines which entity a record refers to and returns a persistent ID. Data enrichment then uses that ID to append attributes like firmographics, contact details, and technographics. Resolution answers who a record is, and enrichment answers what else you know about them. Most workflows run them back to back.
What are the main identity resolution API providers?
The landscape splits by audience. Consumer and adtech options include LiveRamp, Twilio Segment, FullContact, Tilores, and AWS Entity Resolution, which stitch cookies, device IDs, and consumer PII into a person-level graph. For B2B go-to-market, ZoomInfo resolves partial records to verified companies and contacts, which is the relevant category for sales, marketing operations, and RevOps teams.
Is deterministic or probabilistic matching better?
Neither wins outright. Deterministic matching is dependable when clean, unique identifiers exist. Probabilistic matching extends coverage when they do not, in exchange for matches you have to validate. Strong providers blend both, using exact fields where they exist and scored matching to reach the records that would otherwise go unresolved.
Can an identity resolution API work in real time?
Yes. Real-time endpoints resolve a record in milliseconds for live personalization, routing, and lead enrichment, while batch processing handles large backfills at lower cost. Many teams use both, resolving new records on capture and refreshing existing ones on a schedule.
How does identity resolution help with data decay?
Business data ages constantly as people change roles and companies change details. Re-resolving and re-enriching records on a schedule refreshes them against the current state of the graph, holding your CRM accurate over time instead of letting it drift.
