> For the complete documentation index, see [llms.txt](https://help.delpha.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.delpha.io/delpha-api-and-mcp/api/rate-limits.md).

# Rate limits

Your allowance is counted **per credential owner and per operation** — per team for an API key, per OAuth client for the client-credentials flow — in fixed 60-second windows: **3000 requests per minute** on submit and synchronous operations (policy `submit`) and **6000 per minute** on poll operations (policy `poll`). Each operation publishes the policy that governs it in `x-rate-limit`, and every response the API renders names the one that applied in `RateLimit-Policy`. `GET /v1/pricing` has only the shared floor described below: it takes no credential, so there is no owner to count an allowance against, and its `x-rate-limit` publishes the floor alone.

Every response the API renders — success and error alike — reports what is left. The exceptions are the two the gateway answers before the API sees the request, **401** and **403**, and every response of `GET /v1/pricing`, which counts no allowance; they carry none of these headers:

* `X-RateLimit-Limit` — the allowance for this operation in the current window.
* `X-RateLimit-Remaining` — requests still available in it.
* `X-RateLimit-Reset` — when the window resets, as **UTC epoch seconds** (not a delay).
* `RateLimit-Policy` (`"submit";q=3000;w=60`) and `RateLimit` (`"submit";r=2999;t=37`) — the same figures as the structured fields of `draft-ietf-httpapi-ratelimit-headers`, an Internet-Draft rather than a published standard, so their syntax is provisional; the `X-RateLimit-*` triple carries the same figures and is not subject to that draft.

Exceeding your allowance answers **429** with an `Error` body (`code: rate_limited`), `Retry-After` set to the seconds left in the window, and the headers above with `X-RateLimit-Remaining: 0`. Nothing is charged — the request is refused before it is validated or admitted.

A second, coarser limit protects the service as a whole: a per-operation floor of **50 requests/second with a burst of 100** (**100/second, burst 200** on poll operations) that every caller of that operation shares. Crossing it answers **429** with a `GatewayError` body and `Retry-After: 1`, and carries **no** quota headers — those requests are refused before the API sees them. Below that floor, one caller's traffic cannot consume another's allowance.

`Retry-After` on a **202**, **503** or **504** is a poll or backoff hint and carries no quota meaning; only on a 429 does it mean "your window resets in N seconds". Honour it wherever it appears, poll at the pace it suggests rather than in a tight loop, and back off exponentially with jitter after a 429.

#### Published floors

| Sustained rate      | Burst | Applies to          | Operations |
| ------------------- | ----- | ------------------- | ---------- |
| 50 requests/second  | 100   | submit, synchronous | 19         |
| 100 requests/second | 200   | poll                | 16         |

#### What a 429 looks like

Your allowance for this operation is exhausted:

```json
{
  "status": "ERROR",
  "status_code": 429,
  "message": "Rate limit exceeded for this operation's allowance (submit: 3000 requests per 60 s). Retry after the interval in the Retry-After header.",
  "code": "rate_limited"
}
```

The per-operation floor shared by all callers was crossed:

```json
{
  "status": "ERROR",
  "status_code": 429,
  "message": "Rate limit exceeded. Retry after the interval in the Retry-After header."
}
```

The first carries a machine-readable `code` and the quota headers; the second is the gateway's own refusal, which has neither. Back off exponentially with jitter from the `Retry-After` value rather than retrying on a fixed interval.

`GET /v1/pricing` is governed by its floor alone: no allowance is counted per caller, and its responses carry none of the quota headers.

These floors are **per operation and shared by every caller of it** — they sit above your own allowance, which is counted per credential owner. Above a floor the gateway answers **429** itself, before the API sees the request, and sets `Retry-After`.

That refusal carries no quota headers: those report what is left of *your* allowance, not of a floor shared with everyone else. Treat the published numbers as the contract, honour `Retry-After`, and back off exponentially.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.delpha.io/delpha-api-and-mcp/api/rate-limits.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.