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

# Rate Limits and Quotas

> Per-tier request rates, monthly quotas, and 429 retry behavior for the Alterscope Developer API.

The API enforces a per-minute rate limit (with a short burst allowance) and a per-month request quota, both keyed to your plan tier. The values below are the live plan limits.

## Per-tier limits

|                       | Free    | Analyst  | Team      | Enterprise | Custom    |
| --------------------- | ------- | -------- | --------- | ---------- | --------- |
| Requests / minute     | 20      | 100      | 500       | 2,000      | 5,000     |
| Burst                 | 10      | 20       | 50        | 200        | 1,000     |
| Requests / month      | 50,000  | 500,000  | 5,000,000 | Unlimited  | Unlimited |
| WebSocket connections | 1       | 5        | 25        | 100        | 500       |
| Signed webhooks       | —       | —        | 25        | Unlimited  | Unlimited |
| Risk-events WebSocket | No      | Yes      | Yes       | Yes        | Yes       |
| Webhook replay window | —       | 1 day    | 7 days    | 30 days    | 90 days   |
| Data retention        | 28 days | 180 days | 730 days  | 2,555 days | Unlimited |

Custom plans are arranged directly with sales. Enterprise and Custom monthly request quotas are uncapped.

## Rate-limit headers

Every authenticated response carries the current rate-limit state, not just `429`s. Read these headers on successful responses to throttle proactively, before you ever hit the limit:

| Header                  | Meaning                                                                                                      |
| ----------------------- | ------------------------------------------------------------------------------------------------------------ |
| `X-RateLimit-Limit`     | The token-bucket capacity the limit is measured against for your key.                                        |
| `X-RateLimit-Remaining` | Tokens left in the current window after this request. When it reaches `0`, the next request may be rejected. |
| `X-RateLimit-Reset`     | Unix timestamp (in seconds) when the window resets and tokens replenish.                                     |

<Note>
  The headers are set on success responses as well as on `429`, so you can watch `X-RateLimit-Remaining` trend toward `0` and slow down before a request is rejected.
</Note>

A simple proactive strategy: if `X-RateLimit-Remaining` is low, pause until the `X-RateLimit-Reset` timestamp before sending more requests rather than waiting for a `429`.

## When you exceed the per-minute limit

A request over the per-minute rate returns `429 Too Many Requests` with the rate-limit headers above plus a `Retry-After`:

```http theme={null}
Retry-After: 60
X-RateLimit-Limit: <your bucket capacity>
X-RateLimit-Remaining: 0
X-RateLimit-Reset: <unix timestamp when the window resets>
```

Wait for the `Retry-After` interval (in seconds) before retrying, and prefer exponential backoff if you hit the limit repeatedly. The body follows the standard [error envelope](/develop/get-started/errors#rate-limit-responses).

<Note>
  For write requests, retrying after a `429` is safe to do with an idempotency key (`X-Idempotency-Key`) — the same key replays the original result instead of performing the action twice.
</Note>

## Tips

* Use the `limit` and [pagination](/api-reference/pagination) parameters to fetch only what you need.
* Subscribe to [WebSockets](/develop/realtime/websockets) or [webhooks](/develop/realtime/webhooks) for live data instead of polling.
* If you consistently approach a limit, contact sales about a higher tier.

See [Errors](/develop/get-started/errors) for the full status-code reference and [Scopes](/develop/get-started/scopes) for what your key can access.