Rate limits

How many requests per minute and how many at once your organization may make, and how to react when you hit a limit.

The ceiling

Every organization may make 300 requests per minute across the whole REST API.

Rule	Detail
Counted per	Organization — not per API key. Creating extra keys does not raise your allowance.
Window	One minute, fixed. The count resets at the start of each minute.
Applies to	Every endpoint and every verb — reads and writes alike.
Penalty	None. Going over does not suspend your key or reduce your next window.

Normal integration traffic stays far below this ceiling. It exists to keep one runaway integration — a retry loop, a misconfigured sync — from degrading the API for everyone.

The limit applies only to requests authenticated with an API key. People using the app in a browser are not affected.

Every organization may also have at most 3 requests in flight at once across the whole REST API. Like the per-minute ceiling, this counts per organization, not per API key: two integrations of the same organization share the 3 slots.

A request over this limit is not refused at once. It waits up to 2 seconds for one of your other requests to finish, and then runs. A short burst is absorbed without errors. If no slot frees within those 2 seconds, you get a 429 with Retry-After: 1:

HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json

{ "error": "Rate limit exceeded. Retry in 1 second." }

A request refused this way still counts against your per-minute ceiling. A client that retries in a tight loop reaches that ceiling within seconds.

Run your requests one after another, or at most 3 in parallel. Firing tens of requests in parallel does not make a sync faster: the extra requests wait or are refused.

When you go over the per-minute ceiling

The request is refused, not queued. Nothing is written, nothing is partially processed, and you get a 429:

HTTP/1.1 429 Too Many Requests
Retry-After: 23
Content-Type: application/json

{ "error": "Rate limit exceeded. Retry in 23 seconds." }

Retry-After is a whole number of seconds — how long until your next window starts. Wait that long and your full allowance is back.

Both limits answer with the same 429 body, so one retry path handles both: wait Retry-After seconds and send the same request again.

Handling it in your client

Treat `429` differently from other errors

It is not a failure of your request: nothing was rejected on its merits. The same call will succeed once the window rolls over or a slot frees. Never treat a 429 as final — a report built from the other responses silently misses the refused data.

Retry the same page

If a paginated read gets a 429, retry the same request with the same cursor. Do not skip to the next page.

Honor `Retry-After`

Read the header and sleep for exactly that many seconds before retrying. Do not retry immediately — retries inside the same window are refused too.

If ten workers hit the ceiling at once, they all get the same Retry-After and would all resume at the same instant. Add a small random delay on top.

Make retried writes idempotent

If you retry a POST, send the same Idempotency-Key you used originally so a request that did go through is never duplicated.

Example:

async function callApi(path: string, init: RequestInit): Promise<Response> {
  const res = await fetch(path, init);
  if (res.status !== 429) return res;

  const retryAfter = Number(res.headers.get("Retry-After") ?? 1);
  const jitter = Math.random();
  await new Promise((r) => setTimeout(r, (retryAfter + jitter) * 1000));

  return fetch(path, init);
}

Staying under the limits

Limit parallelism to 3 requests per organization. A queue with 3 workers is enough; more workers only produce 429s.
Page with limit=100 instead of many small pages. See Pagination.
Batch your syncs. A nightly job that walks 5,000 records at full speed will hit the ceiling; pace it at ~4 requests per second and it never will.
Cache what rarely changes — task types, tags, workspaces, members. Re-reading a registry on every call burns your allowance for nothing.
Back off on errors. A loop that retries a 4xx immediately, forever, is the exact scenario this ceiling exists to contain.

If 300 is not enough

The ceiling is the same for every organization and is not configurable by you. If a legitimate workload genuinely peaks above it, get in touch and describe the use case — the limit is adjustable on our side.