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 account-level and network-level quotas should both exist
An account-level quota answers a simple question: how much has this specific key used. It is the natural first thing to track, and it is not enough on its own, because a key is just a credential, and credentials can be multiplied. Someone determined to exceed an account-level limit can often just create another account, generate another key, and start a fresh quota, unless something else is tracking a dimension that does not reset just because a new credential was issued.
That is what network-level quotas are for. Every network, one /24 block for IPv4 addresses or one /48 block for IPv6, gets a shared 2,500 request free allowance a day, counted across both keyless traffic and any keys registered from that network. An account-level limit alone would let someone generate new keys indefinitely to keep resetting their free allowance. A network-level limit closes that specific gap, because it is tracking where the traffic is actually coming from, not just which credential happened to be attached to it.
Neither measure alone is sufficient, and it is worth being specific about what each one protects against, since they solve different problems. Account-level tracking protects against a single credential being used far beyond what it should be, which matters for billing accuracy and for catching a leaked key being used somewhere it should not be. Network-level tracking protects against the free allowance specifically being multiplied through repeated signups, which is a different failure mode that account-level tracking alone cannot see, since each new account looks perfectly normal in isolation.
Running both together does create a legitimate complication: multiple genuine users sharing a network, such as a company behind a small number of public IP addresses, could in theory bump into a network-level ceiling that has nothing to do with any individual user's actual usage. We handle this with rolling IP slots, a fixed number of distinct addresses a key can be used from, and quota headers that show exactly how many of those slots are in use against the limit, so a legitimate shared network can see its real standing rather than hitting an opaque wall with no explanation.
We think this is a case where the simpler design, tracking one dimension only, would actually be worse for honest users, not just less protective against abuse. A network-only limit would penalize an account for other unrelated activity on the same network. An account-only limit would leave the free allowance open to being multiplied indefinitely by anyone willing to create enough accounts. Running both, with visibility into each through response headers, is more moving parts, but it is the version that actually protects what a free allowance is supposed to protect without quietly punishing the people using it as intended.