Rate limits

Early access limits

These rate limits apply only for the duration of the early access program.

Rate limits keep shared capacity fair and latency predictable. They apply per account: every API key on an account shares the same limits.

Resolve limits

Limit	Value	429 code
Requests	10 per second	RATE_LIMITED
Concurrent requests	8 at once	CONCURRENCY_LIMITED
Tokens	1,000,000 per minute	RATE_LIMITED

These limits apply to POST /v1/resolve. A request over a limit returns 429 with the code above and a Retry-After header.

• Requests are counted over a rolling one-second window. Every resolve request counts, including one that fails.
• Concurrent requests count from when a resolve starts until it finishes.
• Tokens are the usage.input_tokens of successful resolves. Failed resolves do not debit this token-rate allowance.

The token allowance refills continuously, about 16,667 tokens a second, up to one minute's allowance. A resolve can start while any allowance remains and is charged its actual usage when it finishes, so the last resolve can take the allowance below zero. New resolves return 429 RATE_LIMITED until it refills.

Schema, policy and alias limits

Limit	Value	429 code
Requests	60 per minute	RATE_LIMITED
Concurrent requests	4 at once	CONCURRENCY_LIMITED

These limits apply to registering, reading and moving schemas, policies and aliases. They are separate from the resolve limits and use no tokens.

Request size

Request	Maximum body
POST /v1/resolve	8 MiB, including any inline schema, state or policy
Schema, policy and alias calls	4 MiB

A larger body returns 413 REQUEST_TOO_LARGE.

Shared capacity

All accounts also share service capacity. When it is full, a request returns 529 CAPACITY_BUSY, even below your account's limits.

Stay within the limits

• Queue requests in your application and keep at most 8 resolves running per account.
• After a 429 or 529, wait at least the Retry-After seconds, then retry within a bounded deadline. See retries.
• Branch on error.code, not the message. RATE_LIMITED covers both the request and the token limit.
• Read Retry-After from each response instead of hard-coding waits. Limits can change.