// Matching
Match records that refer to the same entity.
Link records that describe the same person or company — even when the spelling, casing, or formatting differs — with a confidence score on every match.
Who this is for
- Developers linking a record against an existing dataset before insert
- Data teams resolving the same entity across multiple systems
- RevOps teams unifying accounts split across spellings
The problem
The same customer exists as three records across your systems, spelled slightly differently in each. Exact string comparison can't link them, so history stays split and every cross-system report is wrong.
Where it goes wrong
Exact comparison misses the obvious
"Acme Inc" and "ACME, INC." are the same company to a human and different strings to your code. String equality links neither.
Split identity, split history
When the same customer isn't matched across systems, their activity, spend, and support history fragment across records and no report tells the truth.
How it works
Send the records to compare
Provide the record you're checking and the set to match it against, along with the identity fields that matter.
Matching scores candidates
Exact and fuzzy matching compare normalized identity fields and return candidate matches with a confidence score.
Decide with confidence
Above your threshold, treat records as the same entity and link or merge them; below it, send the pair to review.
How Zapinner solves it
Normalize first, then score
Matching is most accurate on normalized identity fields, so canonicalize names, emails, and companies first. Matching then scores candidate pairs and returns a confidence value rather than a naive yes/no.
Match at write time
The highest-leverage place to match is before you insert a record: check whether it already exists, and update instead of creating a duplicate. This turns cleanup into prevention.
Match a record against a set
curl -X POST https://zapinner.com/api/v1/match \
-H "Authorization: Bearer $ZAPINNER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"record": { "name": "Jon Smith", "email": "j.smith@acme.io" },
"against": [ { "id": "con_1a2b", "name": "John Smith", "email": "j.smith@acme.io" } ],
"fields": ["name", "email"]
}'
# -> { "match": true, "confidence": 0.94, "id": "con_1a2b" }Reliability & security
Confidence, not guesses
Every candidate carries a score so you set the bar. Nothing is treated as the same entity below the threshold you choose.
The outcome
Unified entities across systems, linked history, and cross-system reports that finally agree — with a confidence value behind every link.
Frequently asked
- How is matching different from deduplication?
- Matching links a record to an existing entity (often at write time); deduplication collapses duplicates within a dataset. They share the same scoring engine — matching is the one-to-many lookup, dedupe is the whole-set pass.
- What confidence threshold should I use?
- It depends on your tolerance for false merges. Start conservative, review the borderline band, and tune the threshold from real results rather than guessing.