Rate limits

120 requests a minute, per key, with the budget on every response.

The budget#

120 requests a minute, counted per API key rather than per IP address. That distinction matters if you are on a connector platform: Zapier and Make egress from shared addresses, so an IP-based limit would have every customer of theirs sharing one budget with strangers.

Issuing a second key does not buy a second budget in any meaningful sense — please do not shard traffic across keys to get around this. If you have a real need for more, say what it is.

Reading the headers#

RateLimit-Limit: 120
RateLimit-Remaining: 116
RateLimit-Reset: 37

• RateLimit-Limit — the ceiling for the window.
• RateLimit-Remaining — what is left in it.
• RateLimit-Reset — seconds until the window rolls over.

They are on every response, not only on a 429, so a well-behaved client can slow down before it is refused.

Being limited#

HTTP/1.1 429 Too Many Requests
Retry-After: 23

{"error":{"code":"rate_limited","message":"too many requests for this token"}}

Wait for Retry-After and try again. Do not retry immediately, and do not retry in a tight loop: back off.

Staying well under it#

Most integrations that hit this limit are polling when they should be listening.

• Use webhooks. One delivery when something changes beats a request every few seconds asking whether it has.
• If you must poll, use updatedSince on GET /bookings and ask only for what has changed, newest first. A minute apart is plenty.
• Ask for bigger pages. limit=100 is one request where the default would be two.
• Cache event types. They change rarely; fetching them before every booking is wasted budget.

The document at /openapi.json is not counted against your budget, and needs no key.

Last reviewed 28 September 2026.