# Rate limits

Transactional HTTP traffic is rate-limited per organization and per endpoint. Each response reports the current window through X-RateLimit headers, and breaching the limit returns 429.

Every Transactional endpoint enforces a request-per-minute ceiling, scoped by organization and by endpoint. Limits are generous by default and documented per endpoint in the [API Reference](/transactional-api/http/reference) — if you need more throughput on a specific endpoint, open a ticket with the expected peak rate and we will raise the ceiling on your account.

## Reading the headers

Every response includes three headers with the current window state. Log them in production — they are the cheapest way to spot a client that is about to hit the wall.

```
X-RateLimit-Limit      1200
X-RateLimit-Remaining  1195
X-RateLimit-Reset      1893452400
```

| Header                  | Meaning                                       |
| ----------------------- | --------------------------------------------- |
| `X-RateLimit-Limit`     | Total requests allowed in the current window. |
| `X-RateLimit-Remaining` | Requests left before the window tightens.     |
| `X-RateLimit-Reset`     | Unix timestamp when the counter resets.       |

## When you hit the limit

Requests that exceed the window return **`429 Too Many Requests`**. The body is empty; the `X-RateLimit-Reset` header tells you when to retry.

> **Tip**: Back off exponentially rather than retrying in a tight loop. A client that hammers a 429 response keeps the window full and never recovers — waiting until `X-RateLimit-Reset` resolves the situation cleanly.

## What's next

- **[Errors](/transactional-api/http/errors)** — every status code you might receive, including `429`.
- **[API Reference](/transactional-api/http/reference)** — per-endpoint documentation.