Available 1 October 2026

Every ecommerce and operations team has seen it: a customer types a perfectly good postcode, your address tool “helps”, and the order ships to a street with the same name in a different town.

That is the failure mode we set out to kill.

Fetchify’s Address Find API has a Best Match option (best_match_only). Integrations use it when they want one confident address back: checkout, CRM capture, Zapier, bulk cleanse instead of a list to pick from.

The old rule was too generous. If any part of the typed query loosely overlapped the top search hit, we accepted it. A house number 2 could validate 22. A building name could validate a property in another city. A street name could beat the postcode the customer actually typed.

A wrong address that looks verified is worse than an empty result. Downstream systems treat it as done.

What we changed

Two things, both in Address Find.

1. Best Match now checks the result, not just the search score.

The top hit still comes from search. We then refuse it unless it really is the same property:

• House and unit numbers must match exactly. 2 is not 22, 201, or unit 2-4.
• If the query includes a full postcode, the result has to agree with it. We will not “correct” PA2 8AD into a different town because the street name exists elsewhere.
• Street and locality have to overlap. A lucky prefix on one token is not enough.
• Building name plus postcode, with no house number, is not unique enough. We return no match.

Postcode-only search is unchanged. If someone types only CM14 4EL, we still return a property at that postcode. That is a lookup, not a claim that we identified a specific house from thin air.

2. Messy UK typing is handled before search.

People type 2Brunel instead of 2 Brunel. We now split that glued house number for UK queries so search can see the 2 and the building name as separate words. Compact postcodes such as CM144EL are left alone. Flat suffixes such as 2A and ordinals such as 9th Street stay intact.

This is UK-specific. Best Match itself still works for every country we support.

Before and after

These are real query shapes from production traffic, simplified.

t d

Old Best Match

No match is not an error. The API still responds 200 with an empty list:

{ "results": [] }

That is the same empty response Find already used. Your integration should treat it as “we are not confident” and keep what the customer typed, or prompt them to confirm line 1 and postcode.

What this means if you use Best Match

You may see more empty results and fewer silently wrong addresses.

That is the point.

If you verify or cleanse addresses:

• Send line 1 + postcode. That is the query Best Match can stand behind.
• Extra names, PO references, and company lines in the same string make a unique match harder. Prefer the delivery line and the postcode.
• Do not assume Best Match will invent a property from a street name alone.
• If you fall back to a full Find (a list of suggestions) when Best Match is empty, you are opting back into a looser guess. That is fine for an autocomplete dropdown. It is not the same as a verified address.

Why we did it this way

We could have pinned the customer’s postcode and rewritten the rest of the line around it. That still guesses.

We chose the stricter option: if we cannot identify the property, we say so.

Checkout, logistics, and compliance teams would rather stop and ask than print a label for the wrong door.

Best Match remains an opt-in extra on Address Find. Existing list-style Find behaviour is unchanged.

If you already pass best_match_only, you do not need to change your request shape. You may want to make sure your UI and cleansing jobs handle an empty results array the way you handle “no confident match” today.