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.
Eleven thousand rows of customer addresses sat in a spreadsheet, useful for invoicing and useless for planning. A sales operations team wanted to redraw its territories based on where customers actually were, not on the county lines someone had picked years earlier, but a spreadsheet full of street addresses cannot be sorted by geography. It can only be sorted alphabetically, which is not the same thing.
The fix was a single batch job. The team exported every unique address from its customer list and sent them to /v1/forward as one bulk request, since a list of addresses counts each item as one billed request rather than charging per call the way eleven thousand separate lookups would. What came back was a location match for each address, including latitude and longitude, the structured coordinates a mapping tool or a spreadsheet formula can actually work with.
With coordinates attached to every customer, the territory redesign became a data problem instead of a guessing problem. The team could cluster customers by proximity, measure how evenly revenue was distributed across a proposed set of regions, and see immediately when a territory boundary split a dense customer cluster in half for no good reason. None of that was visible when the only location field was a text address that a spreadsheet could not measure distance against.
The team also ran the country and region fields on each match against the reps' existing account assignments, which surfaced a handful of accounts that had drifted into the wrong territory over time, customers who had moved offices or been assigned to a rep in a neighboring region by mistake years earlier and never corrected. Cleaning that up was a side effect nobody had planned for, and it turned out to matter more to quota fairness than the territory redesign itself.
Because the whole customer list was geocoded in one pass rather than trickling in over time, this was closer to a one-time project than an ongoing integration. The team ran the batch, exported the results back into its planning spreadsheet, and did not need to call the endpoint again until the next major territory review. For that kind of workload, the free daily allowance covered the run without needing prepaid credit at all, and the whole project took an afternoon rather than a multi-week mapping engagement with an outside vendor.
The bigger shift was in how the team thought about its own data afterward. Once addresses had coordinates attached, questions that used to require a consultant, like which regions were underserved or overloaded relative to customer density, became questions the team could answer itself with a spreadsheet and a bit of arithmetic. The geocoding step was the only part that required an outside service, and it was also the smallest part of the project.
A batch of addresses does not need to be a customer list. Store locations, service territories, event venues, anything that lives in a spreadsheet as a text address can go through the same process. Batch limits and request formatting are covered at /docs/forward-geocoding/ and /docs/rate-limits/.