Why free support tiers should still get real answers
A support queue that only gives thoughtful answers to paying customers is telling free users their questions are not worth solving properly.
The trouble with API keys that never expire
A key that never expires is convenient in exactly the way that makes it easy to forget it exists. It gets generated once, embedded in a configuration file or an environment variable, and then it simply keeps working, indefinitely, with nobody revisiting whether it should. Years later, the person who generated it may have left the company, the project it was created for may have been decommissioned, and the key itself may be sitting in a forgotten server, a leaked repository, or an old backup, still fully valid, because nothing about the system ever asked it to prove it was still needed.
This is a real, underappreciated security problem, not a hypothetical one. Keys leak through committed configuration files, through logs that captured a request header by accident, through old backups that outlive the project they belonged to. A key that never expires means every one of those leak vectors stays dangerous indefinitely, with no natural point at which the exposure closes on its own. A key that gets rotated or reviewed periodically at least bounds how long a given leak stays exploitable, even if the leak itself was never detected.
We do not think the answer is forcing expiration dates that break integrations without warning, which trades one problem for a different, equally frustrating one: a key that stops working mid-production because of a rotation policy nobody communicated clearly. The answer is visibility and control that make rotation a deliberate, informed choice rather than something that either never happens or happens as an unplanned surprise. Quota headers on every response, including a count of how many of a key's IP slots are in use, give an ongoing signal about whether a key's usage pattern still matches what it was originally issued for, which is exactly the kind of information that should prompt a periodic "does this key still need to exist" review.
The broader industry habit of treating a key as a permanent, install-it-once credential comes from prioritizing initial integration convenience over the entire lifetime of that credential's existence. It is genuinely easier, on day one, to generate a key that never needs touching again. That convenience is front loaded, and the cost, an old, unmonitored, unrotated key sitting somewhere as a permanent liability, is back loaded onto a future incident nobody is thinking about on day one.
We think the healthier default is treating a key less like a fixed installation and more like a credential with an ongoing relationship to the account: visible in real time through the requests it makes, reviewable periodically, and revocable without drama when a project it belonged to has actually ended. None of that requires forcing expiration on anyone. It requires making it easy enough to see what a key is actually doing that letting an old one linger forever stops being the path of least resistance.