Why your call allowance is pooled, not per key
Adding keys does not add allowance. That is deliberate, and here is the reasoning.
A question we get often, and one of the few where the answer surprises people enough that they ask twice: if my plan includes 500,000 calls and I create five keys, do I have 2.5 million calls?
No. The allowance belongs to the account and is shared across every key on it.
The reasoning
Keys are an organisational tool. You make a separate key per site, per environment, per client, so you can rotate one without disturbing the others and see usage broken down sensibly. That is a good reason to have many keys and it has nothing to do with volume.
If allowance were per key, then creating a key would be creating quota. The natural response to hitting a limit would be to make another key rather than to move up a plan — and we would have built a pricing model that punishes tidy engineering. You would be choosing between organising your keys sensibly and paying less, which is a choice nobody should have to make about their own architecture.
So: make as many keys as your architecture wants. It costs nothing.
What this means practically
Your dashboard shows both. Usage per key, so you can see where it goes. One pooled total against your plan, because that total is what you are billed against. If one key is eating the pool, the per-key view is how you find it in about ten seconds.
A runaway loop on staging spends production's allowance. They share a pool. Set a per-minute rate limit on keys that should be quiet — it is a separate control from the monthly allowance and it exists exactly for this.
Refused calls count. A broken integration retrying an invalid key spends your allowance, and that is deliberate. If refusals were free, the traffic you most want to notice would be the traffic you never see on a bill.
Sizing a plan
The number that matters is not your page views. It is your page views divided by how well you cache.
If you hold the entitlement token properly — and you should — you call us when the token approaches expiry, not on every request. A site serving a million page views a month might make a few thousand calls. A site serving ten thousand page views with no caching at all might make ten thousand.
So before moving up a plan because you are near the ceiling, check whether you are caching. Most people who think they need a bigger plan need a token cache.