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

# Rate limiting

> Understand Breet API rate limits, retry headers, and best practices for handling 429 responses.

Breet enforces rate limits on certain endpoints to ensure platform stability and fair usage across all integrations.

## Limits

| Endpoint                                                                              | Limit                   |
| ------------------------------------------------------------------------------------- | ----------------------- |
| [`POST /payments/withdraw/address`](/api-reference/withdrawals/withdraw-stable-coins) | 200 requests per minute |
| `GET /trades/pbc/sell/rates`                                                          | 20 requests per minute  |

Rate limits are applied **per integration and per route**. This means hitting the withdrawal endpoint does not affect your rate limit on the rates endpoint, and vice versa. Limits are tracked using the authentication credentials (`x-app-id`) in your request headers.

## Response headers

Rate-limited endpoints include the following headers in every response:

| Header                  | Description                                                                                |
| ----------------------- | ------------------------------------------------------------------------------------------ |
| `X-RateLimit-Limit`     | Maximum number of requests allowed per window (e.g., `200`).                               |
| `X-RateLimit-Remaining` | Number of requests remaining in the current window.                                        |
| `X-RateLimit-Reset`     | Unix timestamp (in seconds) when the rate limit window resets. Included on every response. |
| `Retry-After`           | Number of seconds to wait before retrying. Only included on `429` responses.               |

### Example response headers

```
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 199
X-RateLimit-Reset: 1769099817
```

## Handling rate limits

When you exceed the rate limit, the API returns a **429 Too Many Requests** status code. See [error handling](/errors) for the full 429 response format. To handle this gracefully:

1. Check the `X-RateLimit-Remaining` header before making requests. If it is approaching `0`, slow down.
2. If you receive a `429` response, use the `Retry-After` header (value in seconds) to determine how long to wait before retrying.
3. Add a retry loop so transient rate limit hits don't break your integration.

### Example retry logic

```javascript theme={null}
async function withdrawWithRetry(payload, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch("https://api.breet.io/v1/payments/withdraw/address", {
      method: "POST",
      headers: {
        "x-app-id": APP_ID,
        "x-app-secret": APP_SECRET,
        "X-Breet-Env": "production",
        "Content-Type": "application/json",
      },
      body: JSON.stringify(payload),
    });

    if (response.status !== 429) return response.json();

    const retryAfter = response.headers.get("Retry-After");
    const waitMs = Number(retryAfter) * 1000;
    await new Promise((resolve) => setTimeout(resolve, Math.max(waitMs, 1000)));
  }

  throw new Error("Rate limit exceeded after retries");
}
```

## Best practices

* **Batch operations** where possible to reduce the total number of API calls.
* **Monitor headers** proactively. Don't wait for a `429` to start throttling.
* **Queue withdrawals** on your end and process them at a steady rate below the limit.
