Setting Quotas and Expiry on API Keys

One account can issue many API keys, each with its own quota and expiry. This is not only access control — it is the cheapest way to turn "who spent what" from one opaque bill into readable data.

Choose the protocol group when creating the key

Creating a key requires choosing a protocol group, which determines the endpoints it can reach:

The wrong group shows up as a 401, and the error will not say why. It is the most common setup problem here, and a second look at creation time saves a lot of debugging.

The key is shown in full only once, at creation. Copy it then.

Quotas: putting a ceiling on spend

A key with a quota stops working when the quota is spent, and stops costing money. A few practical patterns:

• A separate, small-quota key for experiments. A debugging script with an accidental loop is a real risk, and the quota is the only backstop for it.
• Issue keys to colleagues rather than sharing your own. Usage and quota are then tracked per person, problems can be attributed, and offboarding is one click.
• Separate production from development. Experiments should not eat the production quota, and production traffic should not be buried under development noise.

The value of a quota is that it is a hard boundary: better to cap it up front than to study the bill afterwards.

Expiry: keys that retire themselves

Give short-lived keys an expiry date and they stop working on their own, with nothing to remember to revoke.

Good candidates:

• Temporary access for an outside collaborator
• A one-off data processing job
• A short evaluation or trial

Long-running services use keys without an expiry — but pair them with a quota. A key with neither a quota nor an expiry is the one configuration where nothing catches a problem for you.

If a key leaks

Disable that key in the console; it takes effect immediately. This is the main payoff of one key per purpose: disabling one does not disturb anything else you are running, so there is no scramble to reconfigure services at midnight.

Afterwards, filter the usage records by that key and check for calls you do not recognise.

Day-to-day guidance

• One key per purpose; do not share a single key everywhere
• Give every key a quota, even a generous one
• Always set an expiry on temporary keys
• Keep keys out of your repository; read them from environment variables
• Do not forward credential-bearing import links (see "Importing Desktop Client Config with CC Switch")

After setting a key up, send one request and confirm it appears in the usage records — that is the only way to know the key is really in use and the configuration really took effect.