Building a simple geofencing alert for a logistics app
A logistics company wanted a plain alert the moment a delivery truck entered or left a specific customer's site, without building or licensing a full fleet tracking platform.
Verifying an address matches its stated postal code before checkout
A shopper who autofills a checkout form from a saved browser entry, or copies an address from an old email, sometimes ends up with a postal code from one location paired with a city name from another, an easy mistake to make and an easy one to miss when reading over a filled-in form quickly before clicking submit. An online store shipping physical goods found this exact mismatch behind a steady, low-level trickle of misdirected or delayed deliveries, each one small on its own and collectively a real cost in reshipping and customer frustration.
The fix was a cross-check run automatically at checkout, before an order was confirmed. The postal code entered on the form went to /v1/postcode, which resolves what location that code actually corresponds to. The store compared the resolved location against the city and region the shopper had also entered on the same form, and where they clearly disagreed, rather than letting the order through and discovering the mismatch only once a delivery went to the wrong place, the checkout flow paused with a plain prompt asking the shopper to double check the postal code and city before continuing.
The store also ran the full entered address through /v1/forward as a second layer, since an address can pass the postal code and city cross-check while still having a genuine problem elsewhere, a street that does not exist under that name or a number outside the plausible range for that street, and the match confidence returned by the forward geocoding call gave the checkout flow a second signal to weigh alongside the postal code comparison, flagging clearly poor matches for the same quick confirmation prompt.
The store was deliberate about how much friction this added. Most orders passed both checks instantly and moved through checkout with no visible change at all, since the overwhelming majority of shoppers enter their own address correctly the first time. Only the smaller number of orders with a genuine mismatch saw the confirmation prompt, and even then it took a shopper only a few seconds to review and correct, or confirm the address was in fact correct as entered, since an occasional legitimately unusual address could still trigger the check without actually being wrong.
This kind of check pays for itself specifically because the cost of catching a mismatch before shipping is so much smaller than the cost of an order that has already shipped to the wrong place, a reshipment plus a delayed or lost original delivery plus, often, a frustrated customer who is now less likely to order again. Fixing it in the few seconds before an order is placed, rather than the days it takes to discover and correct a shipping problem after the fact, moved that cost from significant to close to nothing.
Every order triggered one postal code check and one address check, a workload that scaled directly with sales volume and stayed inside the free daily allowance for a store of moderate size most of the year, with prepaid credit covering busier periods without requiring any special planning ahead of time.
Documentation for both endpoints is at /docs/postal-code-lookup/ and /docs/forward-geocoding/, and general error handling behavior for both is covered at /docs/errors/.