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, not to a loop of PATCH calls.
The 429 response#
{
"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 /authper request — see AuthenticationAPI. - 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.