The trouble with API keys that never expire
A key issued years ago, never rotated, and still valid today is not a convenience. It is a liability nobody has actually looked at in years.
Why per-country pricing tiers are a bad idea
Some location data pricing pages carry a table that charges different rates depending on which country a lookup targets: a lower rate for countries with widely available, well-established address data, and a higher rate for countries where coverage is harder to build and maintain. The logic sounds defensible on its face, harder data costs more to source, so it should cost more to query. In practice, per-country pricing turns geography into a pricing lever in a way that is difficult to justify once you look closely at who ends up paying more and why.
We charge one flat rate per request regardless of which country a lookup targets. Every endpoint and every compatibility host costs the same, worldwide, whether the address, IP, or coordinate in question is in a market with abundant public geographic data or one with comparatively sparse coverage. There is no country-by-country price table to navigate before you can estimate a bill.
Part of our reasoning is practical: per-country pricing adds real complexity to something that should be simple to reason about. A customer with global traffic, which describes most real applications operating online, cannot calculate an expected bill from a single rate. They have to model the country mix of their traffic and multiply each segment by a different number, turning a straightforward unit economics calculation into a small forecasting exercise that has to be redone every time the traffic mix shifts.
There is a fairness dimension too, one that is easy to miss if you only think about it from the pricing table rather than from who is actually affected. Countries and regions with less established digital infrastructure or less mature open geographic data tend to be lower income markets, on average, more often than not. Charging a premium specifically for looking up locations in those markets, because the underlying data was harder to build, effectively taxes exactly the users and applications serving those regions, at the moment they are trying to reach a market that a flat global rate would treat the same as any other.
We think a single global rate is the more honest reflection of how the product should be evaluated: not by how expensive a specific country was to source data for, but by what a request costs to serve across the system as a whole. Some countries genuinely require more ongoing work to keep accurate. That is a cost we absorb as part of running a worldwide service, not a cost we pass selectively onto whichever customer happens to be querying the harder market that week. A worldwide product should have a worldwide price, and geography should describe where a lookup points, not what it costs to ask.
This is also simply easier to keep honest over time. A single global rate has no table to quietly revise country by country as internal costs shift. One number, applied everywhere, is a promise that is much harder to walk back selectively than a pricing grid nobody outside the company ever fully audits.