Rate limits

Limits are per API key — and, for publishable keys, per key+IP — enforced server-side. Exceeding one gets a 429 with a Retry-After header: wait that many seconds before retrying, don’t hot-loop.

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.

A rate-limit outage on our side fails open, not closed: 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.