Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Drawing delivery zones around a warehouse
A regional grocery chain opened a second warehouse and needed an answer to a simple question before it could promise same-day delivery: which customers could actually be reached from the new building within a reasonable drive, and which ones were still better served by the original site.
Drawing that line by hand, with a compass and a guess at road distance, was the first attempt, and it produced a delivery zone that looked reasonable and performed badly. Some addresses inside the circle were forty minutes away on the only road that reached them. Others just outside it were closer than the map suggested.
The better approach starts with turning addresses into coordinates. A call to /v1/forward takes an address and returns a match, including a latitude and longitude field, the kind of structured location a distance calculation needs instead of a street name a routing tool has to guess at. The warehouse address gets geocoded once. Every order address in the customer list gets geocoded in the same batch, since a bulk request counts each address as one billed item rather than charging per call.
With coordinates on both ends, straight-line distance from the warehouse to each customer becomes a plain calculation the grocer's own system can run. Zones stopped being a hand-drawn circle and became a boundary built from the actual locations being served, updated automatically whenever a new customer address came in. When the warehouse's effective range needed to shrink because delivery times were slipping, the boundary could be redrawn from the same data instead of redrawn by eye.
The reverse direction mattered too. Customer service occasionally had only a set of coordinates from a delivery app, no clean street address, and needed to know which zone and which store that point belonged to. /v1/reverse takes a coordinate pair and returns the address components for that location, turning a pin on a map back into something a warehouse routing table could use.
None of this required the grocer to build or license a mapping platform. The geocoding step was the only missing piece, and it plugged into logistics software the company already ran in house. A few thousand addresses were re-geocoded when the new warehouse opened, with a smaller trickle of new orders geocoded every day after that, comfortably inside the free daily allowance most operations this size use, with room to grow into prepaid credit if order volume climbed.
The lesson generalizes past grocery delivery. Any business drawing a service boundary around a physical location, whether a warehouse, a repair depot, or a same-day install crew, needs the same two things: a reliable way to turn an address into a coordinate, and a reliable way to turn a coordinate back into an address when the data arrives from the other direction. Both come from the same key.
Request and response formats for both endpoints are documented at /docs/forward-geocoding/ and /docs/reverse-geocoding/.