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.
Building a disaster-response resource map
During an active weather emergency, information about where help is needed and where help is available arrives fast and in no consistent format at all. A regional relief coordination group found itself collecting shelter locations, supply drop points, and reports of people needing assistance from volunteers texting in whatever description came to mind, a cross street, a landmark, a partial address, a set of coordinates copied from a phone's map app.
None of that is directly usable on a shared map without a common format underneath it. The coordination group needed every incoming report converted into the same thing, a coordinate pair, regardless of how it arrived. Reports that came in as text, an address or a description close enough to one, went through /v1/forward to get a location match. Reports that came in as coordinates, copied from a phone's location share, went through /v1/reverse to get back a readable address and administrative area, useful for showing volunteers a plain description of the location rather than a raw pair of numbers on the map.
With every report normalized to a coordinate, plotting them together on one shared map became straightforward, and more importantly, comparable: a supply point and a reported need could be measured against each other by actual distance, which mattered enormously for routing volunteers efficiently rather than guessing at proximity from written descriptions that did not obviously relate to each other.
The group ran this through a lightweight intake form rather than anything more elaborate, since the priority during an active response was speed and simplicity over polish. A volunteer submitting a report did not need to know or care which endpoint handled their particular input format, the intake form decided that based on whether the submission looked like text or like coordinates, and either path ended in the same normalized point on the shared map.
Match quality mattered more here than in most other uses of geocoding, since a report during an emergency that resolves to the wrong location, even by a small distance, can send help to the wrong place at exactly the moment that matters most. The group's intake form surfaced the match confidence returned by the forward geocoding call directly to whoever was reviewing incoming reports, so a low-confidence match got a quick human check before it was trusted and acted on, rather than being plotted with the same apparent certainty as a clean match.
None of this required specialized emergency management software. The coordination group ran its intake form on infrastructure it already had, adding geocoding as the one missing piece that let unstructured, volunteer-submitted location descriptions become something a shared map could actually display and compare.
Request volume during an active response spiked sharply and briefly, the kind of pattern that is hard to plan a fixed budget around in advance. The free daily allowance covered ordinary planning and preparation use between events, and prepaid credit absorbed the spike during an actual response without requiring the group to commit to a larger ongoing plan it would not need most of the year.
Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/reverse-geocoding/.