Address Standardization vs Validation

Search for an address API and you’ll see “standardization,” “validation,” and “verification” used almost interchangeably — sometimes by the same vendor, on the same page. They’re not the same thing, and knowing which one you actually need saves you from either buying more than you need or discovering too late that what you bought doesn’t do what you assumed.

Three Capabilities, Three Jobs

Standardization parses a free-form address string into structured components — house number, street, unit, city, state, postcode, country — and resolves it into a canonical form: abbreviations expanded (“St” → “Street”), formatting made consistent. The output is comparable and matchable, but standardization never checks it against anything external. Feed it “123 Fkae St, Nowhere ZZ” and it will parse and structure that string just as confidently as a real address — it has no way to know the street doesn’t exist.

Validation typically means checking that an address conforms to expected structural or postal formatting rules for its country — right number of components, plausible postcode format, recognized state/region code. It’s a step up from standardization in that it flags structurally implausible input, but it still isn’t confirming the address is real.

Verification (often “deliverability verification”) is the strongest claim: confirming the address actually exists and can receive mail, checked against a postal carrier’s own delivery-point database — USPS in the US, for example. This is the only one of the three that can tell you an address is fake.

Why the Difference Matters

If you need to catch a customer who typed a fake shipping address to abuse a promo, standardization won’t catch it — you need verification. If you need every incoming lead’s address in the same structured, comparable format so your CRM can deduplicate reliably, verification is overkill and standardization is the whole job. Buying the wrong one either leaves a gap (fraud gets through because you only standardized) or adds unnecessary cost and latency (verifying every keystroke of a search-as-you-type field you only needed to standardize for indexing).

Where GoodVat Fits

GoodVat’s Address Standardization API does the first one — parsing and standardizing, at a 10ms p99, with canonical expansions built specifically for deduplication, data matching, and master data management (MDM) use cases. It does not validate postal formatting rules and does not verify deliverability against a carrier database.

curl -X POST "https://api.goodvat.com/v1/address/normalize" \
  -H "Authorization: Bearer $GOODVAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "query": "123 Main St Apt 4, Springfield IL 62701" }'

{
  "houseNumber": "123",
  "road": "main street",
  "unit": "apt 4",
  "city": "springfield",
  "state": "il",
  "postcode": "62701",
  "country": "USA",
  "expansions": [
    "123 main street apartment 4 springfield il 62701 usa"
  ]
}

That response is exactly as useful for a fabricated address as a real one — which is the point: standardization’s job is making the string comparable and structured, not vouching for it.

If your use case is CRM dedup, search indexing, tax jurisdiction lookups, or feeding a golden record in an MDM pipeline, standardization alone gets you there. If your use case is catching fraud, confirming a shipping address before a warehouse ships product, or KYC proof-of-address checks that need certainty an address is real, pair standardization with a validation or deliverability verification step from a carrier-specific provider — standardize first so the input you’re validating or verifying is already clean and consistently formatted.

Read the docs to see the full field reference for what standardization returns.