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.
There is a specific kind of friction that shows up disproportionately around address data: a geocoding API with real coverage claims and a demo on its marketing page, but no way to actually run your own addresses through it without first filling out a form and waiting for a sales representative to reach out. The reasoning behind this gate is usually about qualifying leads or protecting a valuable dataset from casual scraping. The effect, regardless of the reasoning, is that a developer cannot answer the one question that actually matters, does this handle my addresses well, without first having a conversation that has nothing to do with the technical question itself.
We do not gate testing behind a sales conversation. 2,500 requests a day, from any address, with no key required, is enough to run a real batch of your own representative addresses through the API and see what comes back, immediately, without scheduling anything. If a key is what you want next, getting one requires an email address, not a qualifying call about your expected volume or use case.
The instinct to gate testing usually comes from treating evaluation traffic as a cost to be minimized rather than as the actual sales process working correctly. We think that gets the priorities backwards for a technical product specifically. A geocoding API is not a product most developers will trust based on a sales pitch or a demo built around cherry-picked example addresses. It is a product they trust after running their own messy, real-world address list through it and seeing how it actually behaves, including on the awkward cases that a curated demo would never include.
This is also where we are careful to be honest about limits rather than let easy access imply more than it should. Being able to test forward geocoding, reverse geocoding, and autocomplete immediately, without a sales call, does not mean those specific endpoints are being presented as fully finished with verified accuracy across every address pattern. It means you get to find out directly, on your own data, what they actually do, rather than being told what they do by someone whose job is to close the conversation with a signed contract.
A sales call has a legitimate place for genuinely large commitments where a direct conversation about specific needs is useful to both sides. It should not be the gate standing between a developer and the basic question of whether an API's address handling is good enough for their use case. That question deserves a direct answer, from the API itself, on the first afternoon someone decides to find out, not after a scheduled call that happens sometime next week.
We would rather earn a large account the same way we earn a small one: by letting the product answer the question directly. If the address handling holds up on your own real, messy list, that is a better argument for a bigger commitment than anything a sales conversation could say on its behalf.