# Rate limits

> Per-key and per-organisation request limits, the x-ratelimit headers, and how to back off.



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

<TableSection title="Per API key">
  |                                    | Limit            |
  | ---------------------------------- | ---------------- |
  | Reads (`GET`)                      | **300 / minute** |
  | Writes (`POST`, `PATCH`, `DELETE`) | **60 / minute**  |
  | Failed authentication, per IP      | 20 / minute      |
</TableSection>

<TableSection title="Per organisation">
  |                                    | Limit              |
  | ---------------------------------- | ------------------ |
  | Reads (`GET`)                      | **1,000 / minute** |
  | Writes (`POST`, `PATCH`, `DELETE`) | **200 / minute**   |
</TableSection>

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.

<TableSection title="Webhook management calls">
  |                                                                                                          | Limit           |
  | -------------------------------------------------------------------------------------------------------- | --------------- |
  | [`POST /v1/webhooks/{id}/test`](/api-reference/webhooks/test-webhook)                                    | **10 / minute** |
  | [`POST /v1/webhooks/{id}/deliveries/{deliveryId}/retry`](/api-reference/webhooks/retry-webhook-delivery) | **30 / minute** |
</TableSection>

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`.

<TableSection title="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                                         |
</TableSection>

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`](/developers/idempotency).

**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.

<Callout type="tip" title="Polling a lot?">
  Most integrations that hit the read limit are polling something a [webhook](/developers/webhooks) would have pushed. If you need more than these limits, talk to us before building around them.
</Callout>