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 we built this the way we would want to buy it
We build and run a geocoding API. That is the whole company. Every decision described across the rest of these posts, per-request pricing instead of seats, a keyless free tier instead of a countdown trial, compatibility hosts instead of a proprietary format, quota headers on every response instead of a lagging dashboard, traces back to the same simple test we kept applying while building it: would this annoy us if we were the customer on the other end of it.
Most of the bad habits we have written about across this collection fail that test immediately, once you actually imagine being the one paying for them. Nobody wants to discover a rate limit through a failed request in production. Nobody wants an "unlimited" plan that turns out to have a fair use policy attached. Nobody wants a migration that takes a quarter because the previous provider's SDK scattered its shapes through a codebase for years. These are not obscure complaints. They are things almost every developer has experienced from the other side of an API relationship, which is exactly why we do not think they need customer research to identify as problems worth avoiding.
Pricing was the clearest place to apply this. 2,500 free requests a day from any address, with no key at all. When you need more, sign up with an email address and either top up prepaid credit at €0.0001 a request or take an Unlimited key for €50 a month. Every endpoint and every drop-in host costs the same. We did not arrive at this by running a pricing optimization exercise designed to maximize revenue per customer. We arrived at it by asking what a fair, honest price for this specific product would look like to someone who has been frustrated by opaque tiers, overage fees, and enterprise sales calls before, because all of us had been that someone at some point.
The same test applies to smaller decisions that never show up on a pricing page: accepting a key through a header, a bearer token, Basic auth, or a query parameter at no extra cost, because forcing one specific pattern is a needless friction for anyone whose existing code already does it differently. Publishing error codes and rate limits plainly, because guessing at an undocumented failure is a waste of everyone's time. None of these are dramatic decisions. They are the accumulation of not doing the annoying thing, repeatedly, across every part of the product.
We are not claiming this makes every part of the product finished or perfect. We are specific about which endpoints we consider fully working and which, like forward geocoding, reverse geocoding, and autocomplete, we describe carefully rather than oversell, because overselling is its own version of the same failure: telling a customer what they want to hear instead of what is actually true. Building the product we would want to buy means building it honestly, including about its current limits, not just building the parts that are easy to be proud of. That is the standard we set for ourselves, and it is the one we intend to keep being measured against.