One company, several strings

A CRM says “IBM Corp.” The billing export says “I.B.M. Corporation, Inc.” Another source may use either form.

String equality treats those records as separate companies. match-key-company turns each label into a readable normalized name and a compact match key. Identical keys place records in the same candidate bucket.

Each call costs 0.005 USDC through x402 on Base mainnet. Send one company name: 

POST https://x402.agentutility.ai/match-key-company
Content-Type: application/json

{
  "name": "I.B.M. Corporation, Inc."
}

After payment, the response preserves the submitted value: 

{
  "input": "I.B.M. Corporation, Inc.",
  "normalized": "ibm",
  "match_key": "ibm"
}

Read the normalized name first

normalized shows how the endpoint interpreted the input. Text is lowercased, joining punctuation is removed, and accents are folded. Legal endings such as Inc, LLC, Corp, Ltd, and GmbH disappear.

Common business abbreviations expand too. intl becomes international, while mfg becomes manufacturing. An ampersand becomes and.

That field is useful for logs and review screens because a person can read it. If an unexpected merge appears, compare the submitted name with its normalized form before changing any records.

match_key goes further. It reduces each remaining word to a phonetic code, which can place close spellings in the same bucket even when their normalized names differ.

See what each variation changes

| Submitted name | normalized | match_key | |---|---|---| | IBM Corp | ibm | ibm | | I.B.M. Corporation, Inc. | ibm | ibm | | Acme & Sons | acme and sons | akm-and-sns | | Acme and Sons LLC | acme and sons | akm-and-sns | | Northstar Intl. Mfg., GmbH | northstar international manufacturing | nr0str-intrntnl-mnfktrng | | Northstar International Manufacturing | northstar international manufacturing | nr0str-intrntnl-mnfktrng | | Microsoft | microsoft | mkrsft | | Micrasoft | micrasoft | mkrsft |

The last pair shows why both output fields matter. Microsoft and Micrasoft retain different normalized forms, but they share mkrsft. A caller can flag that pair for comparison without hiding the spelling difference from a reviewer.

Word order remains meaningful. Acme North and North Acme produce keys in different token orders, so preserve source order when preparing requests.

Route the endpoint for candidate matching

Choose match-key-company when an agent needs to group business names from CRM exports, invoices, lead files, or marketplace listings. The input schema is one required string: 

{
  "name": "Northstar Intl. Mfg., GmbH"
}

The name must contain non-whitespace text and can’t exceed 500 characters. Invalid JSON returns HTTP 400. An absent name also returns 400, while an overlong value returns 413.

Equal keys indicate a candidate match. For high-value merges, check another business attribute such as a domain or postal address. Legal entity identifiers belong in the final decision when they’re available. For current company facts, route the record to a company-data endpoint.

Use the key as a bucket

For a batch job, call the endpoint once per distinct source string and cache the result. Store the original label for display, then index records by match_key. Any bucket containing multiple source records becomes a merge candidate.

Keep normalized beside the bucket. It tells an agent why punctuation, suffixes, or abbreviations disappeared, while the original value remains available for audit output.

A useful merge record looks like this: 

{
  "match_key": "akm-and-sns",
  "source_names": [
    "Acme & Sons",
    "Acme and Sons LLC"
  ],
  "normalized": "acme and sons",
  "review": "candidate_match"
}