> ## Documentation Index
> Fetch the complete documentation index at: https://docs.particle.pro/llms.txt
> Use this file to discover all available pages before exploring further.

# rate_limit_exceeded

> API rate limit exceeded

|                    |                              |
| ------------------ | ---------------------------- |
| **HTTP status**    | `429 Too Many Requests`      |
| **Error code**     | `rate_limit_exceeded`        |
| **Resolve action** | None; wait for `Retry-After` |

## What happened

The organization sent more than **10,000 requests in one minute**. The limit is the same on every plan, and it is one bucket shared by every key and project in the organization, so another key does not add capacity. Keyless x402 requests are limited separately, per IP address, at 300 attempts a minute.

A 429 that carries an `X-Concurrency-Limit` header is a different limit: too many requests in flight at the same time on one credential (an API key or an OAuth grant), rather than too many over the minute. The header gives the maximum number of requests one credential may have running at once. Cap your client's concurrency at or below that number and retry. Enterprise and Marketplace plans are not subject to the concurrency limit.

## Response headers

Responses for API-key-authenticated requests include rate limit headers so clients can track their usage:

| Header                  | Description                                             |
| ----------------------- | ------------------------------------------------------- |
| `X-RateLimit-Limit`     | Maximum requests allowed per minute                     |
| `X-RateLimit-Remaining` | Requests remaining in the current window                |
| `X-RateLimit-Reset`     | Seconds until the rate limit window resets              |
| `Retry-After`           | Seconds to wait before retrying (only on 429 responses) |

## How to fix

Wait `Retry-After` seconds, then continue; `X-RateLimit-Remaining` tells you how close to the limit you are before a 429 lands. Spread a burst over the minute or run fewer workers rather than retrying at once, and if `Retry-After` is longer than a job's deadline, reschedule the job instead of polling. The wrapper in [Handle errors and retries](/recipes/handle-errors) does all of this.