Rate limits

Allowances are counted per workspace, not per key and not per source address. Two keys in one workspace draw from the same allowance, and the dashboard’s own traffic does not count against it.

Every workspace has two windows, checked in this order:

1. a burst window — requests per minute;
2. a daily window — requests per day.

A request that is refused costs nothing in either window.

Headers on every response

Served or refused, every response carries:

Header	Meaning
X-RateLimit-Limit	Requests allowed in the window this response was counted against.
X-RateLimit-Remaining	Requests left in that window.

The headers describe whichever window governed the outcome — the refusing one on a refusal, the tighter burst window otherwise. There is no X-RateLimit-Reset in v1; Retry-After answers that question at the moment it matters.

When an allowance is spent

HTTP/1.1 429 Too Many Requests
Retry-After: 17
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

{ "error": { "code": "rate_limited", "message": "..." } }

Retry-After is whole seconds, never less than one. Wait at least that long before retrying; a client that retries on a fixed short interval will keep being refused and will learn nothing from it.

Allowances by plan

Plan	API keys	Requests / minute	Requests / day
Consumer Standard	0 — no API access	—	—
Consumer Advanced	2	30	5,000
Enterprise Basic	5	60	25,000
Enterprise Standard	10	150	75,000
Enterprise Pro	25	300	250,000

These are the values the API enforces at the time of writing. Your own workspace’s figures are always available from the account endpoint as external_requests_per_minute and external_requests_per_day; read those rather than hard-coding a row of this table.