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.
Routing support tickets by time zone
Routing a support ticket by billing country sounds like it should work and mostly does not. Billing country tells you where an account was set up, not where the person filing the ticket is sitting right now, and a company with support agents spread across three shifts kept sending replies that landed at two in the morning for customers who happened to be traveling, working remotely from a different country, or simply living somewhere their billing address did not reflect.
The company switched to routing by the customer's actual current time instead. Every inbound ticket carries the visitor's IP address, which /v1/ip resolves into country, region, city and coordinates, along with a time zone field on the same response. That time zone, not the billing country on file, decided which shift the ticket landed in. A ticket arriving from an IP currently inside working hours for its region went to whichever shift was staffed and awake in that part of the world. One arriving well outside working hours got queued for the next shift that could reasonably expect a reply to land at a normal hour.
For tickets that needed a scheduled callback rather than an async reply, the team took the extra step of passing the resolved coordinates to /v1/timezone, which returns both the IANA time zone name and the UTC offset for that point, calculated for whatever future moment the callback was being scheduled against. That mattered because offsets shift with daylight saving changes at different times in different countries, and a callback booked three weeks out needed the offset that would actually be in effect on that date, not the one in effect today.
The result was fewer replies sent at obviously bad hours and a routing system that adapted automatically as customers moved, traveled, or simply lived somewhere their account record did not reflect. It also gave the team a genuinely useful metric it had not had before: how many tickets were arriving outside any shift's working hours at all, which turned into a data-backed case for adjusting shift schedules rather than a hunch from one tired agent.
None of this depended on the customer entering anything. The IP address was already part of every request the support widget made, so the whole system ran without an extra form field or a prompt asking someone to confirm their time zone, which people tend to skip or get wrong when traveling anyway.
Request volume tracked one-to-one with ticket volume, comfortably inside the free daily allowance that comes with every My Geocode key for a help desk of this size, with the usual prepaid option available if ticket volume grew past that. The team never had to think about cost once it was running, which is generally the sign that a piece of infrastructure is doing its job quietly in the background.
Full field references for both endpoints are at /docs/ipv4-lookup/ and /docs/timezone-lookup/, and rate limit behavior is covered at /docs/rate-limits/.