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

# Rate Limits

> Requests per minute by plan, what a rejection looks like, and how to stay under it.

Rate limiting caps how *fast* you call the API. It is independent from
[credits](/credits), which cap how *much* you call it over a billing period.

## Limits by plan

| Plan             | Requests per minute | Requests per period |
| ---------------- | ------------------: | ------------------: |
| **Free**         |                  30 |      1,000 one-time |
| **Professional** |                 200 |       5,000 / month |
| **Max**          |                 500 |      20,000 / month |
| **Enterprise**   |          negotiated |          negotiated |

The right-hand column is your [credit](/credits) balance divided by the 10 credits a request
costs — the two limits bite at different scales, and this one is the ceiling for the period.

The limit is attached to your API key when the subscription is provisioned, and it travels
with the key — each key has its own window. Enterprise agreements and legacy plans can carry
values outside this table; the key is always the source of truth for what applies to you.

<Note>
  Not sure which applies to you? The MCP tool `get_my_plan` reports the plan and its limits, or
  check the [API dashboard](https://app.alphractal.com/api-dashboard).
</Note>

## The window

A **fixed one-minute window**, counted per API key. There is no queue: a request arriving
over the limit is rejected immediately rather than delayed. The window resets on the minute,
not on a rolling basis, so a burst spent at the start of a window has to wait for the next
one.

## Being rejected

Over-limit requests return **HTTP 429** with a plain-text body:

```
Rate limit exceeded. Please try again later.
```

A rejected request never reaches the data layer, so it costs no credit.

## Staying under it

* Spread bulk backfills over time instead of firing everything at once.
* Prefer a **wider date range in one request** over many small ones — the credit cost is the
  same either way, and it uses a single slot in the window.
* Cache responses for series that only update daily. Most on-chain, macro and sentiment
  metrics produce one datapoint per day, so polling them every minute returns the same value.