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 sandbox environments should be free
Some APIs offer a sandbox environment that is functionally separate from production: different keys, sometimes different endpoints, occasionally its own pricing structure or its own more restrictive limits. The intention is reasonable, giving developers a safe space to test without touching real usage or real billing. In practice, a sandbox that requires its own signup step, its own key, or its own paid upgrade step, adds friction to exactly the moment when a developer is trying to decide whether your API is worth the friction at all.
We do not run a separate sandbox. Testing and production use the same free daily allowance: 2,500 requests a day from any address with no key, and another 2,500 a day once you add a key, counted per network. There is no separate test mode with its own limits to learn and no paid tier gating serious testing behind a purchase. Whatever you build against during evaluation is the exact same system you deploy against, at the exact same free allowance, before you ever spend a euro.
This matters because a sandbox that behaves even slightly differently from production is testing the sandbox, not testing your integration. If a separate sandbox uses simplified or fake response data instead of the real dataset, you find out about real-world data quirks only after going live, which defeats a large part of what testing is supposed to catch in the first place. Testing against the real system, with real data, using the real free allowance, means what you learn during evaluation is actually true of what you will run in production.
There is a cost to us in not gating sandbox access behind a separate paid step: some fraction of that free testing traffic will never convert into a paying account, the same tradeoff as any generous free tier. We think that cost is worth it, because the alternative pushes exactly the wrong incentive onto a developer deciding whether to build against your API at all. A paid or heavily restricted test mode asks someone to commit financially before they know whether the product fits their use case. A free, fully functional testing path lets that decision get made on the merits, after actually trying it.
None of this means testing has no limits at all. The same 2,500 requests a day that cover light production use also cover testing, and a large-scale load test against that allowance will hit the same ceiling a small production integration would. That is intentional. The free tier is generous enough for real evaluation, not infinite, and treating it as your permanent test environment for a high-volume product is a different thing than using it to confirm an integration works before switching to paid usage.
A sandbox should answer one question honestly: does this work the way I expect, using the real thing. Charging for that answer, or answering it with anything other than the real thing, defeats the purpose either way.