Deduplicate before you write, not after
Cleaning duplicates in a nightly batch job is a losing game. Here is why entity matching belongs at write time, and how to add it without slowing your API down.
Almost every team starts the same way: let records in, then run a cleanup job later. It feels pragmatic and it scales terribly. Every downstream system — billing, email, analytics — reads the dirty data before the cleanup runs, so you are perpetually reconciling.
Why after is the wrong time
- Duplicates fan out: one becomes three across your CRM, mailer, and warehouse before the batch job fires.
- Merges get risky: once systems reference both IDs, merging is a migration, not a cleanup.
- Metrics lie in the meantime: activation and retention are computed on split identities.
Match at write time
Entity matching at the point of write turns the problem from cleanup into prevention. Before you insert, ask whether this record already exists — fuzzy on name, normalized on email and phone — and get a confidence score back.
curl https://zapinner.com/api/v1/match/entity \
-H "Authorization: Bearer $ZAPINNER_KEY" \
-d '{"record":{"name":"Jon Smith","email":"j.smith@acme.io"},"against":"contacts"}'
# -> { "match": true, "confidence": 0.94, "id": "con_1a2b" }Above a confidence threshold you update the existing record; below it you insert. The duplicate never exists, so nothing downstream has to un-learn it.
The objection is always latency. A single matching call on the write path is milliseconds and only runs on creates, not reads — a price worth paying to never run a reconciliation job again.
Stop rebuilding data utilities.
Start free with 1,000 credits a month across every capability — no credit card required.