Monitor your key's usage before you hit a limit
Watching your quota headers as you go tells you when a limit is approaching, well before a request actually gets rejected.
Cross-check an address against its postal code
A customer can type a real street address and a real postal code that do not actually belong together, most often by transposing digits or copying an old postal code into a new address. Neither field alone reveals the problem, since both are individually valid.
Resolving each field independently
Geocode the full address with /v1/forward to see what postal code it actually resolves to, and separately look up the postal code the customer typed with /v1/postcode to see what area it covers.
GET /v1/forward?q=10 Downing Street, London&limit=1{
"status": "ok",
"results": [
{"formatted": "10 Downing Street, London, UK", "lat": 51.5033, "lon": -0.1276, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "op678", "components": {"postcode": "SW1A 2AA", "city": "London"}}
]
}GET /v1/postcode?code=SW1A 1AA&country=GB{
"status": "ok",
"postcode": "SW1A 1AA",
"country_code": "GB",
"results": [{"lat": 51.5014, "lon": -0.1419, "components": {"city": "London", "region": "Greater London"}}]
}Comparing the two results
If the postcode component from the address lookup does not match the postal code the customer typed, as in this example, that is a mismatch worth flagging, even though both the address and the postal code independently checked out as real. Comparing the two components directly is more reliable than comparing distance between the two sets of coordinates, since a postal code area can be small enough that even a genuine match will not sit exactly on the address's coordinates.
A second example: a bigger mismatch worth catching earlier
The same check also catches a far more obvious error, a postal code entered for an entirely different country or region than the street address itself, such as a UK-format code paired with an address that actually resolves inside another country. Comparing the country component from the address result against the country parameter used for the postcode lookup, before even reaching the more detailed postcode comparison, is a cheap first check that filters out this kind of larger mistake early.
What to do with a mismatch
Show the customer both values side by side and ask them to confirm which one is correct, rather than silently picking one over the other or rejecting the order outright. A transposed digit is an easy fix once pointed out, and a genuine edge case where a postal code legitimately covers a boundary between two commonly used values is rare enough to handle with a quick manual confirmation.
A common mistake to avoid
Do not compare the two sets of coordinates directly with a distance threshold as a substitute for comparing the postcode components themselves. A postal code area can be geographically small enough that even a completely correct match will show some distance between the postcode's representative point and the address's specific building coordinates, and a small area code can also be geographically large enough that a genuinely mismatched pair still falls within a lenient distance threshold. Comparing the postcode text itself is a more direct and reliable check than trying to infer a match from distance.
An edge case worth allowing for
A postal code area that sits right on a boundary between two administrative regions can legitimately return a component set that looks slightly different depending on which endpoint resolved it, even when both are correct. Treat a close but not exact textual match, such as a difference only in how a region name is written, with a lighter touch than a fully different postal code entirely.
Checking many orders at once
For a batch of existing orders rather than a single new submission, both endpoints accept a bulk POST array, so a backlog of orders can be checked by sending the addresses as one bulk request to /v1/forward and the postal codes as another bulk request to /v1/postcode, then comparing the two result arrays by position.
Request cost
This check uses two requests per order, one for the address and one for the postal code, both counted against your daily allowance the same as any other lookup. That is a reasonable cost for catching an error that would otherwise show up as a failed delivery.
Catching a mismatched postal code before an order ships is worth the second request it takes to check. Details on both endpoints are in the forward geocoding docs and the postal code lookup docs.