Names nicknames related
Heuristicnames_nicknames_relatedBest-effort — fuzzy, approximate, or inferred; check the confidence score.
Check whether two names plausibly refer to the same person. True when both are the same formal, one is a nickname of the other, or they share a formal parent ('Liz' and 'Betty' → both Elizabeth). For de-duplication and patient-record matching workflows.
Parameters
astringrequiredbstringrequiredCall it
curl -X POST https://api.snipget.ai/v1/names/nicknames/related \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{"a":"Liz","b":"Betty"}'Example response
{
"a": "Liz",
"b": "Betty",
"related": true,
"reason": "share formal name(s): ['Elizabeth']",
"shared": [
"Elizabeth"
]
}FAQ
What does this answer?
It tells you whether two names plausibly belong to the same person. 'Liz' and 'Betty' both trace back to Elizabeth, so it returns related true and names the shared formal name. Great for catching duplicate records that a plain text match would miss.
How sure is the yes or no?
It is best-effort, based on a maintained nickname list, not a certainty. A 'related' answer means the names are linked through a known formal name, not proof that the two records are the same individual. Use it as a strong hint, then confirm with other fields.
When does it say related?
When both names are the same formal name, when one is a known nickname of the other, or when both are nicknames of a shared formal name. The reason field explains which rule matched.
What does it NOT do?
It only compares first names and nicknames. It does not look at last names, dates of birth, or addresses, and it is English-only. Two unrelated people who share a first name will still look related.
What if one of the names is unknown?
If either name is missing from the catalog, it returns related false with a reason and confidence 0, not an error. That is a 'cannot tell'. When both names ARE in the catalog but share no formal name, related is false at confidence 1.0 — a confident 'different person'.