Rate limits

Two fixed windows of one minute: one per key, one per workspace.

The two buckets

Bucket	Limit	Window	Protects
Per API key	600 requests	60s	You, from one buggy loop consuming the whole workspace's budget.
Per workspace	1,800 requests	60s	The platform, so ten keys do not multiply the ceiling by ten.

Headers

Every authenticated API-key response carries the state of your key's bucket.

text

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 583
X-RateLimit-Reset: 41

X-RateLimit-Reset is seconds until the window turns over. Read these and pace yourself; do not wait for the 429.

When you exceed

json

HTTP/1.1 429 Too Many Requests
Retry-After: 41

{
  "error": "RATE_LIMITED",
  "message": "Too many requests. Retry after the window resets.",
  "request_id": "req_01J..."
}

Windows are fixed, not sliding. That means the boundary is a real edge: 600 requests at 10:00:59 and 600 more at 10:01:00 both succeed. We are telling you this rather than letting you discover it, because pacing evenly is cheaper for both of us than discovering the edge in production.

If our rate limiter is unavailable

It fails open. A limiter that takes the API down when its own datastore blinks turns a capacity problem into an outage. You will simply not see the headers for those requests.