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.
The case for treating postal code lookups as first class
Product priorities show up in pricing structure and documentation depth long before they show up in any explicit statement about what matters most. An endpoint tucked into a lower pricing tier, or documented in three sentences next to a fully detailed page for a flagship feature, is communicating a real fact about internal priority, whether or not anyone intended to communicate it. Postal code lookups are a common victim of this pattern: technically available, rarely invested in, and treated as a minor utility relative to full geocoding.
We priced postal code lookups the same as every other endpoint on purpose, specifically to avoid that quiet demotion. It is covered under the same free daily allowance, billed at the same €0.0001 per request beyond that, or included under the same €50 Unlimited key, exactly like geocoding, IP lookups, time zone, or elevation. There is no discount tier that signals postal lookups are considered less valuable, and no premium tier that signals the opposite. It sits at the same level as everything else, because we think it should.
Equal pricing is a starting point, not the whole argument. The deeper reason postal code lookups deserve first class treatment is that the underlying data genuinely warrants the same seriousness as any other kind of location data. Postal systems are not a simplified version of geocoding. They are their own category of structure, varying by country in format, in the size of area a single code covers, and in how directly the code maps onto administrative boundaries. Building this correctly across multiple countries takes real, sustained attention, the same kind that a flagship geocoding feature gets by default because it is assumed to be the important one.
Treating an endpoint as first class also means it gets the same documentation standard: real examples, a clear description of what data is returned and how it is structured, and honest notes about coverage limitations by country rather than a vague blanket claim. An endpoint documented thinly because it is assumed to be simple tends to stay simple in exactly the ways that matter, because nobody is looking closely enough to notice where it falls short.
There is a practical payoff to this beyond fairness in how we allocate engineering attention. A lot of real applications, shipping calculators, tax jurisdiction checks, service area validation, depend more directly on a correct postal code resolution than on a full street-level geocode. Treating postal lookups as a minor feature relative to geocoding gets the actual dependency backwards for exactly the applications that need this data the most. Giving it equal pricing and equal documentation is not a symbolic gesture. It is closer to correcting a category error that the rest of the industry has mostly inherited without examining.