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.
Pricing a subscription differently by region
Charging the same price everywhere ignores how differently purchasing power and competition vary from one market to another. A software company selling a subscription product wanted to price it lower in some markets and hold the line in others, a common enough strategy, but doing it required knowing which market a visitor was actually in before the price ever rendered on the page.
Asking directly was the first idea and the wrong one. A country selector on a pricing page reads as an invitation to shop for the cheapest option by lying about location, and it adds a decision to a page whose entire job is to get a visitor to a checkout button with as little friction as possible. The company wanted the right price to simply appear.
The fix ran server-side, before the pricing page was returned. /v1/ip took the visitor's IP address and returned a country field, among others, which the pricing page used to select which price table to render. A visitor from a market with the standard price saw the standard price. A visitor from a market where the company had set a regional rate saw that rate instead, with no selector, no extra click, and no visible sign that anything had been detected at all.
The company treated the detected country as a starting point rather than a locked-in fact, since a visitor on a corporate VPN or traveling abroad could be flagged as being in the wrong market for their actual pricing eligibility. Rather than hard-blocking anyone, the checkout flow allowed a support override for the rare case where a customer's actual billing country did not match what the IP suggested, handled as an exception rather than built into the main flow, since building constant doubt into the pricing page for an edge case that affected a small fraction of visitors would have undone the simplicity the whole change was meant to deliver.
One detail mattered enough to call out directly to the finance team: My Geocode itself bills in EUR everywhere it operates, with no regional pricing of its own beyond the standard free allowance, prepaid credit, and Unlimited key. That is a different question from whether a company using the API wants to run regional pricing on top of its own product, which is a decision entirely up to the business built on top of it. The lookup only supplies the country signal. What a company does with that signal, and how it prices around it, stays its own decision.
Request volume followed pricing page views, typically a small fraction of total site traffic since most visitors on a software company's site are not actively pricing the product on a given visit. That kept usage well inside the free daily allowance for most of the year, moving into prepaid credit only during periods of unusually high pricing page traffic, such as around a product launch.
Regional pricing done well should be invisible as a mechanism and obvious as an outcome: the right price, on the first render, no extra step. Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, and pricing details for the API itself are at /pricing/.