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.
Building a weather app that starts from a visitor's location
The worst first impression a weather app can make is an empty search box. A visitor opens the page wanting to know if it will rain today, and instead of an answer, they get a prompt asking them to type in a city name first, an extra step for information the app should reasonably be able to guess.
A weather app addressed this by resolving an approximate starting location the moment a page loaded, server-side, before rendering anything. /v1/ip took the visitor's IP address and returned coordinates along with city and region, giving the app a location to request a forecast for immediately. The forecast itself came from the app's own weather data provider, using those coordinates as the input, so the location lookup and the weather data were two separate pieces working together rather than one service trying to do both jobs.
The app treated the detected city as a starting guess a visitor could always correct, since IP-based location has real limits: it reflects the network a connection is coming from, which is usually close to a visitor's actual location but is sometimes off, particularly on a mobile carrier network where an IP can resolve to a regional hub rather than the visitor's exact town. A clearly visible way to search for a different city sat right next to the detected one, so correcting a wrong guess took one click rather than feeling like the app had failed.
This small change moved the app's most important number, today's forecast for the visitor's own area, from something a visitor had to ask for to something already on screen when the page finished loading. For a weather app specifically, where the entire value proposition is speed to the answer someone wants, removing the search step for the common case of "what's the weather right here" mattered more than almost any other feature the app shipped that year.
The app also used the resolved region to decide which units to show by default, since a visitor detected in a country using Celsius and one detected in a country using Fahrenheit have different expectations for what "72 degrees" means, and getting the default unit right on first load avoided a settings hunt that most visitors would never have bothered with, quietly leaving with the wrong impression of the forecast instead.
Every page load triggered one lookup, which for an app with meaningful traffic pushes past the free daily allowance fairly quickly and into either prepaid credit or an Unlimited key, depending on how predictable the app's traffic pattern is. For a weather app, traffic is famously spiky around storms and unusual weather, exactly when an Unlimited key's flat monthly cost becomes easier to plan around than a variable prepaid bill that might jump right when the app needs to perform its best.
Getting the first screen right, with no typing required, is a small technical decision that shapes how an entire app feels. Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, and pricing for both credit and Unlimited options is at /pricing/.