# Rate limits

> The per-key budgets, the headers that report them, and how to back off.

Source: https://www.propexecutor.com/docs/rate-limits
Whole reference in one file: https://www.propexecutor.com/doc.md

Limits are per API key and generous — a dashboard polling every account it owns should never notice them. They exist to stop one integration from crowding out live trading, which shares the same database.

| Bucket | Methods | Budget |
| --- | --- | --- |
| Reads | `GET` | **1,200 requests / minute** |
| Writes | `POST` `PUT` `PATCH` `DELETE` | **120 requests / minute** |

The same for every plan tier. Your tier decides how many accounts you can run, not how fast you may ask about them.

## Headers

Every response carries your current position:

<!-- Response headers -->
```http
X-RateLimit-Limit: 1200
X-RateLimit-Remaining: 1187
X-RateLimit-Reset: 42
```

| Field | Type | Description |
| --- | --- | --- |
| `X-RateLimit-Limit` | integer | The budget for this bucket. |
| `X-RateLimit-Remaining` | integer | Requests left in the current window. |
| `X-RateLimit-Reset` | integer | Seconds until the window resets and the budget refills. |

## Going over

<!-- 429 Too Many Requests -->
```json
{
  "error": {
    "code": "rate_limited",
    "message": "too many requests — retry in 42s"
  }
}
```

A `429` also carries `Retry-After` in seconds. Wait that long rather than retrying immediately; a tight retry loop spends the next window before it opens.

> **Staying well under**
> Read one account’s [analytics](https://www.propexecutor.com/docs/analytics) object rather than assembling the same picture from several calls — it is one request for the whole thing. And for breaches and passes, prefer being told over asking: polling 1,250 accounts on a timer spends most of your budget learning that nothing happened.