Rate limits

Every API key is rate limited independently, counted in a fixed one-minute window. The limit configured today is 1000 requests per minute per key.

Headers

Every response, whether it succeeds or fails, carries the current state of the limiter:

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 998

X-RateLimit-Limit is the configured ceiling for the window; X-RateLimit-Remaining is what is left before the window resets.

Over the limit

A request that arrives after the counter is exhausted gets 429:

{"error":"rate limit exceeded"}

The window is fixed, not sliding

The counter resets on the minute rather than sliding continuously behind each request. In practice this means a burst that straddles a window boundary can briefly get through more than the configured limit suggests: requests near the end of one window and requests near the start of the next are counted separately, even if they land only moments apart. Do not rely on the limit as a hard ceiling for pacing a client; treat it as a budget to stay well under, not a guarantee of an even rate.

Each key has its own counter

Rate limiting is scoped to the key, not the organisation. Exhausting a test key's counter does not touch a live key's counter on the same account, and vice versa. That makes a dedicated key per environment worth the two clicks: separate keys for test and live traffic, or for separate services, keep one integration's burst from throttling another's. See Authentication for how keys are issued and how test and live keys differ.