Word matching

Users type words themselves, and they type them wrong. The lookup endpoint is built for that.

A request for /words/{word}/clips runs a ladder and stops at the first rung that hits:

1. Normalise. Lowercase, fold accents and trim. Café and cafe are one lookup.
2. Exact match against the catalogue. matchType comes back as exact.
3. Inflected forms. running finds run, mice finds mouse. matchType is forms.
4. Near spellings. Trigram similarity catches recieve for receive. matchType is fuzzy.

Always read matchedWord

The response tells you which word the results are actually for:

{
  "query": "recieve",
  "matchedWord": "receive",
  "matchType": "fuzzy",
  "didYouMean": ["receive", "relieve"]
}

Show matchedWord back to the user when it differs from what they typed. Silently answering a different word than the one someone asked for is how a search feature loses trust.

Controlling the ladder

The match parameter sets how far it runs:

Value	Stops after	Use when
strict	Exact	You are passing words from your own catalogue and want a clean miss
forms	Inflections	You control the input but not its grammatical form
fuzzy	Near spellings	A human typed it. This is the default

strict is the right choice for batch jobs: a fuzzy match that quietly succeeds is worse than a miss you can count.

When nothing matches

The response is 404 with error.didYouMean populated when candidates exist. That is a coverage gap, not a failure; see Coverage.