# Rate Limits

Limits are counted **per endpoint, per IP, per minute**. Each limit is independent: exhausting `POST /auth` does not affect `GET /transactions`. Where one limit spans two endpoints, requests to either count against it.

## Limits

| Endpoint | Requests per minute per IP |
| --- | --- |
| `POST /auth` | 360 |
| `GET /transactions`, `GET /transactions/{id}` | 360 |
| `GET /investments`, `GET /investments/{id}` | 360 |
| `GET /investments/{id}/transactions` | 360 |
| `PATCH /items/{id}` | 20 |

`PATCH /items/{id}` is sized for user-triggered updates. Daily refreshes belong to [auto-sync](/docs/connections/item#auto-sync), not to a loop of `PATCH` calls.

## The 429 response

```json
{
  "code": 429,
  "message": "Too many requests. Please try again later (see Retry-After header in seconds)"
}
```

Further requests to that endpoint keep failing until the minute window resets. Three headers say how long:

| Header | Meaning |
| --- | --- |
| `RateLimit-Limit` | The limit for this endpoint, per minute. |
| `RateLimit-Reset` | Seconds until the counter resets and the endpoint accepts requests again. |
| `Retry-After` | The standard retry hint. Always `60`. |

Wait `RateLimit-Reset` seconds and retry. HTTP clients with standard retry behaviour (for example `got`) already honour `Retry-After` on a `429`.

## When you keep hitting a limit

- Reuse the API Key for its 2 hours instead of calling `POST /auth` per request — see [Authentication](/reference/authentication).
- Cap the parallelism of batch jobs against one endpoint and space the calls.
- Look for duplicated requests in normal operation.
- If the application genuinely needs more, contact support with the use case.

Read the guide: [Rate limits](/docs/developer-tools/rate-limits).