Rate Limits
All API endpoints are rate-limited per API key. Default limits apply unless overridden at the key level.Default Limits
Per-key overrides: any API key can carry custom
rate_limit_per_minute and rate_limit_per_day values, applied to every key type (csb_, csu_, cpk_). A value of 0 means “use the global default” for that window — the two windows are independent, so you can override one and leave the other on the default. Contact support to have a limit raised on your key.
Publishable keys (cpk_ prefix) default to 100 requests/minute and can be configured independently.
Quota is scoped to the key, not the organization. Each key gets its own independent budget, so an organization holding three keys has three separate quotas and there is no aggregate ceiling across them. This is deliberate — it lets you put a noisy batch integration behind its own key without it starving your production traffic. It also means splitting traffic across keys raises your total throughput.
Rate-Limit Headers
Every response includes enough state for callers to self-throttle before they hit a 429 — an “informed governor” pattern.
These follow the IETF
draft-ietf-httpapi-ratelimit-headers draft.
Legacy aliases
For back-compat with older SDKs, we also emit:
New integrations should prefer the unprefixed
RateLimit-* headers.
Why most-restrictive wins
If you have 250 requests left in your minute quota but only 8 left in your day quota, the headers report the day state — that’s the one that will trip first.RateLimit-Policy declares all windows so you can plan ahead for the long-tail (daily) one even when minute is the active constraint.
The “informed governor” pattern
Read the headers and pause when you’re getting close to the limit, instead of waiting for a 429:Handling 429 Responses
If you do hit a 429 — usually because your governor wasn’t running, or the quota was already exhausted by another caller sharing the key — the response has both aRetry-After header and a retry_after_seconds field in the error envelope:
Retry-After.