Rate Limits

The limit

60 requests per minute, per API key. Every documented endpoint counts — reads and writes alike.

The limit is per key, not per IP address. Ten integrations in one workspace each get their own 60. Zapier and n8n Cloud send traffic from IP addresses shared by thousands of their customers; because the limit is keyed on your key, their traffic cannot throttle you and yours cannot throttle them.

Ordinary use never approaches the limit: a busy website form produces a few submissions an hour, and a Zap polling every few minutes uses a handful of requests. If you expect sustained traffic above 60 per minute on one key, talk to us before you go live.

Headers

Every response carries:

Header	Meaning
X-RateLimit-Limit	Requests allowed per minute on this key — 60
X-RateLimit-Remaining	Requests left in the current minute

When the limit is exceeded the response is 429 with the standard error object and two more headers:

Header	Meaning
Retry-After	Seconds to wait before the next request
X-RateLimit-Reset	Unix timestamp at which the window resets

HTTP/1.1 429 Too Many Requests
Retry-After: 23
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1788080047
X-Request-Id: 01K4R4Z2N7Q9X0F3M6C8V1B5D2
Content-Type: application/json

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests.",
    "request_id": "01K4R4Z2N7Q9X0F3M6C8V1B5D2",
    "documentation_url": "https://developers.bytephase.com/errors#rate_limit_exceeded"
  },
  "message": "Too many requests."
}

How to behave

1. Read Retry-After and wait at least that long. Do not retry a 429 immediately.
2. Back off exponentially on repeated 429s: 1s, 2s, 4s, 8s… with a little random jitter, up to a sensible ceiling.
3. Send the same Idempotency-Key on the retry, so a request that actually got through before the 429 is not duplicated. See Idempotency.
4. Never retry any other 4xx. Only 429, 423, 5xx and network failures are worth retrying.
5. Queue, don’t burst. If a spam wave hits your website form, queue submissions and drain them at a steady rate rather than forwarding each one as it arrives. The WordPress plugin does this for you.

A minimal retry loop in JavaScript:

async function postWithBackoff(url, body, key, idempotencyKey, attempt = 0) {
  const response = await fetch(url, {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${key}`,
      'Content-Type': 'application/json',
      Accept: 'application/json',
      'Idempotency-Key': idempotencyKey,
    },
    body: JSON.stringify(body),
  });

  if (response.status === 429 && attempt < 5) {
    const retryAfter = Number(response.headers.get('Retry-After') ?? 1);
    const backoff = Math.max(retryAfter, 2 ** attempt) * 1000 + Math.random() * 250;
    await new Promise((resolve) => setTimeout(resolve, backoff));
    return postWithBackoff(url, body, key, idempotencyKey, attempt + 1);
  }

  return response;
}

Zapier and n8n

• Zapier polls each trigger on its own schedule (typically every 1–15 minutes depending on your plan). A handful of Zaps stays far below the limit.
• n8n workflows on a schedule should not poll more often than once a minute per key. A workflow that loops over records and calls the API once per record should add a short wait between iterations.

Limits are per key, so type your keys accordingly

Because each integration has its own budget, keep one integration per system — one for the website, one for Zapier, one for n8n — rather than sharing a key. It keeps the limits independent and, more importantly, keeps the provider type honest.