Rate limits

Two buckets apply to every request — one per API key and one per organisation — and the tighter one wins. All windows are one minute.

Per API key

	Limit
Reads (GET)	300 / minute
Writes (POST, PATCH, DELETE)	60 / minute
Failed authentication, per IP	20 / minute

Per organisation

	Limit
Reads (GET)	1,000 / minute
Writes (POST, PATCH, DELETE)	200 / minute

So four keys polling at full speed share the organisation's 1,000 reads; a fifth gets 429 even though its own 300 are untouched. If you run several integrations against one organisation, plan the total, not each one.

Webhook management calls

	Limit
POST /v1/webhooks/{id}/test	10 / minute
POST /v1/webhooks/{id}/deliveries/{deliveryId}/retry	30 / minute

These two calls have their own, tighter buckets, counted per webhook endpoint. When one of them answers 429, the x-ratelimit-* headers still describe the key's bucket — use retry-after.

Headers

Header	Meaning
x-ratelimit-limit	The limit for this kind of request
x-ratelimit-remaining	How many are left in this window — the lowest of the buckets that apply
x-ratelimit-reset	Unix seconds when the window resets

Every response — success or error — carries the current state in these headers.

The headers are on error responses as well, deliberately: you need x-ratelimit-remaining most when something has already gone wrong.

When you hit the limit#

Over the limit is 429 rate_limited, with a retry-after header giving the seconds to wait. Wait that long — or until x-ratelimit-reset — rather than retrying immediately — a tight retry loop just spends the next window too. Retry writes with the same Idempotency-Key.

If the limiter itself is unavailable (an infrastructure fault on our side, not something you can cause), reads are fail-open — they go through unlimited rather than taking every integration down — and writes are fail-closed: they answer 429 rate_limited until it is back. Treat that 429 like any other.