Rate limits

Limits are per API key — and, for publishable keys, per key+IP — enforced server-side.

On a 429, back off — don’t hot-loop

Exceeding a limit gets a 429 with a Retry-After header: wait that many seconds before retrying.

Key/scope	Default limit
Secret key (sk_)	300 requests/minute, burst 50
Publishable key (pk_) + IP	60 requests/minute
Hold creation, per pk_ key + IP	10/minute (additional cap, on top of the general publishable limit above)

Limits are configurable per tenant. If you’re consistently hitting a limit in production, ask your operator contact whether a higher tier fits their traffic, rather than adding client-side retries that ignore Retry-After.

Fails open, not closed

A rate-limit outage on our side fails open: if the limiter itself is unreachable, your request goes through rather than being blocked. This is a deliberate trade-off — availability over strict enforcement for rate limiting specifically — and it doesn’t affect the anti-double-booking guarantee, which lives at the database level, not in the rate limiter.

Next steps

• Errors — the full error shape, including 429.
• Authentication — which key kind gets which limit.