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.
Personalizing a newsletter send time by time zone
A newsletter sent at 7 AM headquarters time lands in some subscribers' inboxes at a reasonable early morning hour and in others' inboxes well after midnight, buried by the time they wake up and check email, and a publisher running a daily newsletter to an international subscriber base had exactly this problem without realizing how much it was costing in open rates, since the difference showed up as a vague regional pattern in the data rather than an obvious, single explainable cause.
The publisher had approximate location data for most subscribers already, gathered at signup either from a location field or inferred from the signup IP address through /v1/ip, resolved into country and city. What it lacked was a way to turn that location into an actual send time decision, since knowing a subscriber was in a particular country is not the same as knowing the correct time zone to schedule around, especially for larger countries spanning multiple zones.
For each subscriber's resolved location, the publisher's sending system looked up the IANA time zone name through /v1/timezone, storing it against the subscriber's record rather than looking it up fresh on every send. With a real time zone attached to each subscriber, the sending platform could stagger delivery so that the newsletter arrived at roughly the same local hour for everyone, regardless of how many time zones the total subscriber base spanned, rather than firing every copy at once from a single scheduled time.
Open rates improved measurably in the regions that had previously been receiving the newsletter at an inconvenient local hour, the clearest evidence that the original single-send-time approach had been quietly costing engagement in exactly the markets furthest from headquarters time, the ones probably least likely to have been noticed as a problem without directly measuring for it.
The publisher used the stored IANA name rather than a fixed offset specifically so the send time calculation stayed correct through daylight saving changes without needing manual updates, an easy detail to overlook that would have caused the carefully tuned send times to drift out of alignment twice a year in every affected region if a raw offset had been stored instead.
This was a one-time lookup per subscriber rather than a per-send cost, since a subscriber's time zone rarely changes and there was no reason to re-resolve it for every single newsletter issue. That kept the total request volume low relative to the publisher's subscriber base, well within the free daily allowance even accounting for a steady trickle of new signups needing their own first-time lookup.
Send time is one of the more overlooked levers in email marketing precisely because a single average open rate number hides how differently it performs by region, and the fix, once the underlying cause is visible, is a straightforward technical change rather than a content or subject line problem the team might otherwise have spent time chasing instead.
Documentation for both endpoints is at /docs/ipv4-lookup/ and /docs/timezone-lookup/.