https://api.cal.id carries headers describing your current allowance, so a well-behaved integration can throttle itself before it is throttled.
Rate-limit headers
These headers are returned on all responses, including error responses.When you exceed the limit
Once you run out of allowance, Cal ID responds with HTTP 429 Too Many Requests and a JSON body:retryAfter is the number of seconds to wait before your next call is allowed.
Handle limits gracefully
1
Check the status code
Treat
429 as its own case, separate from other errors.2
Wait for retryAfter
Sleep for the number of seconds in
retryAfter — or until X-RateLimit-Reset — before retrying.3
Back off exponentially
If you are still throttled after the wait, double the delay on each subsequent attempt and cap the number of retries.
4
Reduce the call volume
Batch work, cache responses that rarely change (such as event types), and raise the
limit parameter on list endpoints instead of paging one record at a time.X-RateLimit-Remaining, sleep for retryAfter, double the delay on each attempt, and give up after five tries.
A
429 is genuinely transient, so retrying is correct. A 500 often is not: Cal ID returns 500 for scheduling-rule failures such as no_available_users_found_error, which will fail identically on every retry. (Malformed requests return 400, not 500.) Read the response body before you retry. See API integration for details.Related API documentation
API integration
Base URL, authentication, response envelopes, and common pitfalls.
Get your API key
Use separate keys per integration so you can isolate a noisy one.
Webhooks
Receive booking events as they happen instead of polling the API.
API Reference
Every endpoint, with schemas and a live “Try it” playground.