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.
Rate limits should be documented, not discovered
There is a particular kind of bad morning that starts with a spike of failed requests and ends with a developer reading a provider's status page for the first time, trying to figure out whether the failures are an outage or a limit they never knew existed. That morning is entirely avoidable, and the fact that it still happens across this industry is a documentation failure, not an infrastructure one.
A rate limit is not a secret. It is an operational fact about a system, the same as a maximum request size or a supported HTTP method, and it belongs in the same place: written down, before anyone hits it. We publish ours in the rate limits documentation, alongside the authentication and errors pages, so the numbers a developer needs to plan around are available before they write the first line of integration code, not after the first outage-shaped afternoon.
Documentation alone is not enough, though, because limits can depend on which plan you are on, and a document goes stale the moment your account status changes. That is why every response also carries live quota headers: your limit, how much you have used, how much free allowance remains, how much of your network's shared allowance has been used, your remaining prepaid credit, and when the quota resets. You do not have to cross-reference a document against your dashboard to know where you stand. The answer rides along with the response itself, on every single call.
Some providers treat published limits as a competitive weakness to hide, on the theory that a visible number invites customers to negotiate it down or shop it against a competitor. We think that instinct is backwards. A limit nobody can see is not a limit that protects the provider's infrastructure any better. It just means the first time a customer learns the real number is when they are already over it, at the worst possible moment for a growing product, in front of their own users.
There is also a design discipline that documenting limits up front forces onto a provider. If a rate limit is going to be published, it has to be a real number someone is willing to stand behind, not a vague internal threshold that gets adjusted quietly whenever it becomes inconvenient. Writing the number down and putting it in response headers on every call means the limit has to actually be the limit, consistently, which is exactly the property a developer needs it to have.
Discovering a rate limit through a failed request in production is not a rite of passage. It is a sign the documentation did not do its job. Ours is meant to make that particular bad morning something you read about happening to someone else, not something that happens to you.