Skip to main content
Cal ID limits how many API calls you can make over a given window. You do not have to guess where you stand: every response from 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.
Log X-RateLimit-Remaining in your client. Watching it trend toward zero is the cheapest early warning that a job is calling the API too aggressively.

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.
Do not retry a 429 immediately or in a tight loop. Hammering the endpoint keeps you throttled and delays your own recovery.

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.
The first three steps together make a small wrapper you can put every call through. Both versions log 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.

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.