Privacy
Plainly stated, because you are sending us other people’s data.
We do not retain the records you send
The names, emails, phone numbers, dates of birth and addresses in a request are held in memory for as long as it takes to compute the answer, and are then gone. They are not written to a database, not written to logs, and not used to train anything.
This is true of a 5,000-record batch exactly as it is of a single comparison, because batch is synchronous. There is no queue holding your list, no job to poll and no stored result — which is most of why we would rather cap the request size than run it in the background.
What we do keep
Operational metadata only, for billing, abuse prevention and debugging:
| kept | example |
|---|---|
| Request id | req_4f2c… |
| Which API key made the call | sameornot_1a2b |
| The decision returned | match |
| How many records were submitted | 412 |
| Latency and status code | 4 ms, 200 |
| Timestamp | 2026-08-09T21:40:00Z |
That is the complete list. There is no column in our database that could hold a person’s name.
The stats block a batch returns is counted the same way: how many records
carried a phone number, how many pairs we could not resolve. Counts, never values —
and it is computed for the response, not stored.
No third party sees your data
Matching runs entirely in our own process using deterministic rules — no language model, no external API call, no sub-processor receiving personal data on the default path. If that ever changes, it will be disclosed here first and made opt-in.
Playground
The examples on the home page use invented people. Anything you type into the playground is treated exactly like an API request: computed, answered, discarded.
Questions, or something we should be doing differently?
casey@sameornot.com. If your organisation needs a DPA, hashed matching or a signed retention commitment, say so — those get built when a real buyer needs them.