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, 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 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.

Not sure which applies to you? The MCP tool get_my_plan reports the plan and its limits, or check the API dashboard.

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.