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.
Postal codes deserve more respect than they get
Ask a location API for its feature list and geocoding usually leads, IP lookups come next, and postal codes show up somewhere near the bottom, described in a single line as if resolving a postal code to a place, or a place to its postal code, were a trivial lookup with one obvious answer. It is not. Postal systems vary enormously by country: some encode administrative hierarchy directly into the digits, some are alphanumeric, some cover an area the size of a neighborhood and some cover an area the size of a small country. Treating this as a minor utility endpoint undersells how much real structure sits behind it.
We built postal code lookups as a first class endpoint alongside geocoding, IP, timezone, and elevation, not as an afterthought tacked onto the geocoding response. It gets the same pricing as every other endpoint: covered under the free daily allowance, then the same €0.0001 per request or the same €50 Unlimited key as anything else. There is no separate "utility endpoints" tier that treats postal lookups as a lesser feature worth a lesser price and, implicitly, a lesser amount of engineering attention.
Part of why postal codes get underrated is that they look simple from a country where the system is a fixed number of digits mapped cleanly to a small area. That simplicity does not generalize. A postal code lookup needs to actually handle the variety of formats and administrative meanings that exist across different countries, not just the pattern most familiar to whoever built the feature. An API that quietly assumes one country's postal format as the default, and treats everything else as an edge case, is not really offering global postal code support. It is offering one country's system with limited coverage bolted on.
This matters practically in ways that are easy to overlook until they cause a problem. Shipping calculations, tax jurisdiction lookups, service area checks, and regional pricing all depend on getting the postal code layer right, often more directly than they depend on a full street-level geocode. A shipping quote does not usually need a rooftop-accurate address. It needs a correct postal region, resolved consistently. Treating that as a minor feature relative to full geocoding gets the actual dependency backwards for a lot of real applications.
We are not claiming postal code data is a solved problem globally, because postal systems keep changing and coverage quality genuinely varies by country and by how actively a given postal authority publishes updates. What we are saying is that it deserves the same seriousness as any other endpoint: real documentation, the same price as everything else, and the same expectation that it should keep working correctly rather than being the corner of the product nobody revisits once it technically returns a response.