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.
Scheduling webinars that show the right time per attendee
"Join us Thursday at 2 PM Eastern" is precise for exactly the attendees who already think in Eastern time and a guessing game for everyone else, and a B2B software company running regular webinars for an international audience found that a noticeable share of no-shows and late joins traced back to attendees simply doing the time zone math wrong, or not doing it at all and assuming the invite meant their own local 2 PM.
The company's registration form already collected an email address and, for scheduling purposes, an approximate location, either entered directly or inferred from the registrant's IP address at the moment they signed up, resolved through /v1/ip into coordinates along with country and city. Those coordinates fed into /v1/timezone, which returned the IANA time zone name for the registrant's location, giving the company a reliable way to calculate that specific attendee's correct local time for the webinar, rather than relying on the attendee to convert it themselves.
Every confirmation email after that showed the webinar time twice: once in the presenter's own time zone for consistency, and once calculated specifically for that attendee's resolved time zone, spelled out in plain language rather than as an offset a reader had to do further math on. The same dual display carried through to the calendar invite attached to the confirmation, so an attendee adding the event to their own calendar saw it land at the correct local hour automatically rather than needing to trust a manual conversion.
Because webinars were often scheduled weeks ahead, sometimes crossing a daylight saving transition in one region but not another, the company relied on the timezone lookup's ability to calculate the correct offset for the specific future date of the webinar rather than the offset in effect on the day the invitation was sent. Storing the IANA name rather than a fixed offset meant this stayed correct without anyone at the company needing to track which regions were about to change their clocks and adjust invitations by hand.
The measurable result was a meaningful drop in the number of support and sales emails asking to confirm the actual local time of an upcoming session, a small but recurring cost in staff time that had been treated as an unavoidable part of running international webinars before this. Attendance also improved modestly, though the company was careful to note that better attendance likely came from a mix of factors, clearer time zone display being one contributor among several rather than a single explanation.
Volume was light and predictable, one lookup per registrant at signup time, a workload that never came close to the free daily allowance even for a company running frequent webinars, since registration volume for any single event rarely reaches a scale where request cost becomes a meaningful consideration.
Getting a meeting time right for every attendee, individually, rather than asking each person to do their own conversion, removes a small but real source of friction from something as simple as showing up to a scheduled call. Documentation for both endpoints is at /docs/ipv4-lookup/ and /docs/timezone-lookup/.