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 real estate search that ranks by commute distance
Bedroom count, price, and square footage are the filters every property listing site starts with, and they are also the filters that ignore the question a lot of buyers actually care about most: how long would it take to get to work from here. A real estate listing site kept hearing this in user feedback and eventually built the filter directly.
The mechanics required two coordinates and a distance calculation. Every listing on the site already had an address, which needed to become a coordinate through /v1/forward, a batch job run once for the existing inventory and then per listing as new ones were added. A buyer's workplace, entered as a single address in a new search field, went through the same endpoint to become a coordinate on the buyer's side.
With both points as coordinates, distance between a listing and a buyer's workplace became arithmetic the site's own search backend could run directly, no different in principle from filtering by price range, just filtering by distance from a point instead. Buyers could set a maximum commute distance and see only listings within it, sorted with the closest options first, which turned out to be a far more useful way to browse than scrolling a price-sorted list and checking each one's location by eye.
The site was careful about what this filter promised. Straight-line distance is not the same as commute time, since a river, a highway interchange, or a lack of direct roads can make two points that are close as the crow flies into a much longer actual drive or transit trip. The feature was labeled as distance, not commute time, and the site avoided claiming any specific travel time estimate, since building that accurately would require a routing and traffic data source well beyond what a distance calculation between two points can honestly provide.
Even framed conservatively as distance rather than time, the filter became one of the most used on the site within its first few months, particularly among buyers relocating for a new job who had a single fixed point, their new office, and cared enormously about how far from it they'd be willing to live. For that specific and common buyer situation, a distance filter was close enough to the real question to be genuinely useful.
Geocoding volume was driven mostly by new listings coming onto the site, a modest and predictable stream, plus the one-time cost of geocoding existing inventory when the feature launched. Buyer workplace addresses added a smaller, ongoing volume on top of that. Combined, this stayed within the free daily allowance for most of the year for a site of moderate size, with the initial batch job for existing listings being the only point where usage briefly spiked, easily covered without needing to plan ahead for it.
A distance filter is a small addition to a search page, but for a real estate site specifically, where the physical location of a listing genuinely matters more than almost any other factor, it addresses something the standard set of filters simply cannot. Documentation for the endpoint is at /docs/forward-geocoding/.