Connect records with different name strings

Your CRM has “Bob Smith.” An imported contact says “Smith, Robert.” Comparing those strings directly leaves the records apart.

match-key-name gives both names the match key rbrt-sm0. You can use that shared value to find candidate duplicates before deciding which records belong together. The endpoint costs 0.005 USDC per call, paid through x402 on Base mainnet. It’s part of Matchpoint.

Each request takes one name. The response includes the submitted text and a normalized version, plus parsed name fields and a match key. There’s no pairwise score in this response.

For an agent routing a contact-cleaning task, that’s a specific job: turn each name into fields you can compare across source records.

What changes in the response

Send this JSON body to POST https://x402.agentutility.ai/match-key-name through your x402 payment client: 

{
  "name": "Dr. Bób Smith Jr."
}

The result is: 

{
  "input": "Dr. Bób Smith Jr.",
  "normalized": "robert smith",
  "match_key": "rbrt-sm0",
  "first": "robert",
  "last": "smith"
}

The title disappears. So does the suffix. The accent in “Bób” folds away, and the resulting “bob” maps to “robert.”

Those changes affect the returned name fields, too. first is "robert", even though the submitted name used a nickname. Keep your source name for display; the normalized text is useful for comparison.

Recognized titles include “Dr.” and “Mr.” Suffix handling covers “Jr.” and “Ph.D.” among other entries. For example, "Bob Smith Ph.D." also produces "robert smith" with the key "rbrt-sm0".

Accent folding works without a nickname change: 

[
  {
    "name": "José García",
    "normalized": "jose garcia",
    "match_key": "grs-js"
  },
  {
    "name": "Jose Garcia",
    "normalized": "jose garcia",
    "match_key": "grs-js"
  }
]

This array compares selected fields from separate calls. The endpoint accepts a single name per request.

And nickname mappings have boundaries. “Mike” maps to “michael”; “Liz” maps to “elizabeth.” Treat those as matching conventions. A returned expansion doesn’t establish someone’s legal or preferred name.

Name order changes fields differently

A comma matters here.

The endpoint accepts “Last, First” and rearranges it before returning the normalized fields. Without a comma, it retains token order in those fields. Compare these separate-call results: 

[
  {
    "input": "Smith, Robert",
    "normalized": "robert smith",
    "match_key": "rbrt-sm0",
    "first": "robert",
    "last": "smith"
  },
  {
    "input": "Smith Robert",
    "normalized": "smith robert",
    "match_key": "rbrt-sm0",
    "first": "smith",
    "last": "robert"
  }
]

Both keys match. But first and last differ.

That distinction matters when you’re joining datasets whose name order varies. Group records by match_key; inspect the parsed fields before writing them into dedicated given-name and family-name columns.

For names with several words, first is the first normalized token and last is the final token. Middle tokens remain in normalized and contribute to the key. A source that includes a middle name can therefore produce a different key from one that omits it.

Use the key to select candidates

Two people can share “Robert Smith.” Removing “Jr.” and “Sr.” also removes a distinction that your records might need.

So keep each source record’s ID beside its returned key. Use equal keys to collect candidates, then compare another field, such as an email address, before approving a merge. Preserve conflicting values for review.

For an x402 caller, submit the JSON request, handle the payment requirements, and retry with payment through your client. Read the offered amount and network before authorizing payment.

Validate names before that step. The endpoint requires a nonempty string and accepts at most 200 characters after trimming. Missing or blank names return HTTP 400; overlong names return HTTP 413.

Finally, check the returned fields before grouping. An input consisting entirely of recognized titles or suffixes can produce an empty key. Route those records for correction so every blank result doesn’t end up in the same duplicate group.