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 quiet cost of vendor lock-in
Nobody signs up for an API planning to be locked into it. Lock-in does not arrive as a term in a contract you can negotiate away. It accumulates, one convenience at a time, until the cost of switching has quietly grown larger than the cost of whatever problem made you consider switching in the first place.
It starts small. You install the provider's SDK because it saves a few hours of writing HTTP calls by hand. You store the response object shape directly in your database instead of mapping it to your own schema, because that mapping felt like unnecessary work at the time. You build error handling around the provider's specific status codes rather than a general pattern. Each of these choices makes sense on its own, in the moment, under normal delivery pressure. None of them are made with lock-in in mind. All of them add to it.
Years later, the provider raises prices, or has an outage during a busy period, or simply stops being the best option for a feature you now need. Switching should be a matter of picking a new vendor and updating a configuration value. Instead it is a project: rewriting parsing logic scattered through the codebase, rebuilding error handling, retraining whatever internal tooling grew up around the old shape. The switching cost was never charged on an invoice. It was paid for in advance, in small integration decisions nobody flagged as risky at the time.
We built compatibility hosts specifically against this pattern. If your integration already speaks another provider's request and response shape, pointing it at one of our 17 compatibility hosts does not require you to have planned for portability in advance. You get the option to leave without having had the foresight to build for leaving. That is a meaningful difference from most anti-lock-in advice, which tends to say "build against an abstraction layer from day one," which is good advice that almost nobody actually follows under deadline pressure.
Authentication is a smaller example of the same principle. Some providers push you toward one specific auth method, tying your integration to a particular client pattern. We accept a key as an X-API-Key header, an Authorization Bearer header, HTTP Basic auth, or a query parameter, on every host, at no extra cost for any of them. Whatever pattern your existing code already uses for other APIs, ours probably fits it, so you are not rewriting your authentication layer just to try us.
The honest reason lock-in persists across this industry is that it works, commercially. A customer who would leave on price alone often stays because leaving means a rewrite. We think that is a bad trade to build a business on, because it wins the customers who are already unhappy rather than the ones who are genuinely satisfied. If leaving stays cheap, the customers who stay are staying because the product is still worth it, not because the exit door got quietly bricked up somewhere back in year two.