Rate Limiting

​

How limits are enforced

• Limits vary by workspace and endpoint; expect stricter limits on write-heavy operations (bookings, invoices).
• Bursts may be smoothed; sustained high throughput triggers throttling.

​

Headers

• Retry-After — seconds to wait before the next attempt (if provided).
• X-RateLimit-Limit — requests allowed in the window (when available).
• X-RateLimit-Remaining — remaining requests in the current window.

​

Error responses

​

Backoff strategy

• Use exponential backoff with jitter (e.g., base 1s, cap 30s).
• Keep write operations idempotent (e.g., idempotency keys on booking/invoice flows) so retries are safe.
• Space concurrent workers to avoid synchronized bursts.

​

Best practices

• Cache read-heavy data where possible (venues, spaces, products).
• Prefer pagination and filtering to reduce response sizes and request counts.
• Log correlationId, status, and remaining headers to monitor usage.
• Contact support if you need higher limits; share recent correlationId values.

• Reads: ~60 rpm per workspace
• Writes (bookings, invoices): ~20 rpm per workspace
• Webhook delivery retries: exponential with jitter, capped retries