Skip to main content

API rate limits & quotas console

The Developer → API governance page in the dashboard is the self-serve console for the per-key usage limits API: set the org-wide default, override a single key, and see what each key is doing right now — no support ticket, no mailto: hand-off. You need the owner, admin, or developer role. Everyone else in the workspace sees the page but cannot change values.

What this page governs

Three separate knobs live on this page, and they are easy to conflate:
  • Requests per minute (rate limit) — throughput: how many requests a key may make inside each one-minute window. Exceeding it rejects the excess calls with 429 until the window rolls over.
  • Monthly request quota — volume: a hard ceiling on requests counted from the 1st of the month (UTC). Exceeding it rejects every further call with 429 until the month resets.
  • Usage-alert threshold — an advisory early-warning line, expressed as a percent of the monthly quota. Crossing it only flags the key in the console; it never blocks traffic. The monthly quota is the thing that blocks.
Set an org-wide default for the first two, and the threshold, once — every key inherits them unless it carries its own per-key override.

Limits and defaults

Every value you can set is bounded. A value of 0 is rejected outright (a zero cap would hard-block the key; revoke it instead), and the upper bounds below come from the platform — the Org-wide default card shows the same numbers so you cannot save an out-of-range value: Leave a field blank to clear that setting back to the platform default.

Org-wide default

The org-wide default is the tier every API key inherits unless it has its own override.
  1. Open Developer → API governance.
  2. In the Org-wide default card, set the fields you want — requests per minute, monthly request quota, and/or the usage-alert threshold.
  3. Save. Only the fields you touch change; a blank field clears that setting.

Per-key override

Override either limit for a single key when one integration needs more headroom — or a tighter lid — than the rest of the workspace.
  1. In the per-key table, find the key and click Set override (or Edit override on a key that already has one).
  2. Enter a requests-per-minute value, a monthly quota, or both. Leave a field blank to inherit the org default for that dimension.
  3. Save. To remove the override entirely, clear both fields and save — the key goes back to the org default.
Keys with an override are marked Override in the table, next to the effective limits that actually gate the key.

Live usage and headroom

The per-key table reports live counters per key:
  • This minute — requests inside the current per-minute window.
  • This month — requests since the 1st (UTC).
  • Headroom — a bar showing usage against the effective monthly quota. A key crossing the usage-alert threshold is flagged; a key past quota is marked Over quota and starts receiving 429 until the month resets.
The counters refresh when you navigate or save a change; use Refresh to pull the latest numbers on demand. If your workspace has more than 250 active keys, the list is cut and the page tells you it was truncated.

Worked example

Say the org default is 600 requests/minute and 1,000,000 requests/month with the usage-alert threshold at 80. One noisy key needs room: Changing any of these values is enforced on the key’s very next request — a 429-ing key you just raised stops being rejected on its next call.

How an override propagates

A saved value is enforced on the very next request that key makes. The console’s save invalidates the API-side governance cache, so there is no TTL to wait out — a 429-ing key you just raised stops being rejected on its next call, and a key you tightened is bounded from its next call. Every change is audit-logged: org-wide default and per-key override each produce an audit entry you can review under Audit log (look for the developer.api_governance.org_updated and developer.api_governance.key_updated actions).

Program rate limits via API

Everything the console does maps onto the governance API, so CI/CD and infrastructure-as-code pipelines can set the same values without a dashboard login. The endpoints below are the same ones the console calls — a value you set here shows up on the console, and is enforced on the key’s next request either way. Per API key, override the requests-per-minute limit, the monthly request quota, and — optionally — the monthly spend ceiling (integer cents; the per-key budget a leaked key can’t spend past):
cURL
Send null on a dimension to inherit the org default for that dimension; send all null to remove the override entirely. A body with no fields returns 422. A key id your organization does not own returns 404 — the write can never land on another tenant’s key. Ranges match the Limits and defaults table: 1–60,000 requests/minute, 1–1,000,000,000 requests/month. Zero is always rejected. The response returns the override you set plus what actually gates the key after the write:
The usage-alert threshold is org-wide, not per-key: set it with PUT /api/v1/developer/governance/org sending alert_threshold_percent (an integer 1–100, or null to disable flagging). Read the current org default, the threshold, every key’s override, and live usage back with GET /api/v1/developer/governance.
Node SDK
Same loop in a pipeline — the org default and one override, as API calls: Full field semantics live in Per-API-key usage limits API; the JSON envelope above follows the pattern documented there.

Troubleshooting

A key shows Over quota and gets 429. Its month-to-date count passed the effective monthly quota. Raise the quota (per-key override, or the org default) and the very next request succeeds — there is no cache TTL to wait out. If you’d rather the key stop entirely, revoke it on Developer → API keys. A key is flagged as alerting but nothing is blocked. That is the usage-alert threshold doing its job: the key crossed the configured percent of its monthly quota, so the console flags it. Alerting is advisory only; raise the quota or let the month reset. The page returned an error on save. The value was out of range — the allowed bounds are listed in the Limits and defaults table above, and the org-default card shows them inline. Zero is always rejected: blank the field (inherit the platform default) or revoke the key instead. Save succeeded but the key still hits the old limit. Re-check the per-key table: the effective limits column on the row is what actually gates the key. A row whose override you “cleared” by blanking only one dimension still inherits the org default for the other, and a row with a saved override ignores the org default for that dimension. If the counter itself looks stale, hit Refresh. My workspace has hundreds of keys and I can’t find one. The table hydrates at most 250 active keys; when it truncates, the page says so. Drive the same settings through the API (PUT /api/v1/developer/governance/keys/:keyId) or revoke dormant keys to get back under the cap. Who changed this limit? Every org-default and per-key change writes an audit-log entry with the acting user, the new values, and (for overrides) whether the override was cleared. Filter the audit log on the api_governance resource.

Permissions

Reads and writes on this page require the owner, admin, or developer role. The same roles gate the underlying API (/api/v1/developer/governance), so a member who can open the page can also drive it from a script. Give this page to whoever owns your API keys — usually one or two admins — and keep rotating viewers on the read-only API analytics dashboard, where the viewer role can watch throughput, the error breakdown, and per-key usage without touching a limit.