Rate limits

ASAS applies several independent limits. They protect the platform and keep one noisy client from starving others. All of them are authoritative at the organization level — per-key limits are strictly subordinate, so rotating keys never resets a limit.

The limits

Concurrency and credits are orthogonal: you can be under your rate limit but out of credits (blocked), or have credits but be at your concurrent-stream cap (also blocked). Your tier's numbers are visible in the dashboard.

429 responses

When you hit a limit you get 429 with an RFC 9457 body and standard headers:

HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 600
RateLimit-Remaining: 0
RateLimit-Reset: 42
Retry-After: 42
Content-Type: application/problem+json

{ "title": "Rate limit exceeded", "status": 429, "code": "rate_limited", "request_id": "req_…" }

The code distinguishes the cause: rate_limited (request rate), concurrency_limit (too many streams), or quota_exceeded (out of credits).

Handling 429 well

• Always honor Retry-After (seconds). Do not retry sooner.
• Use exponential backoff with jitter for rate_limited.
• Treat quota_exceeded differently — backing off won't help until your balance is topped up. Alert, don't spin.
• Cap concurrency client-side to your tier's stream limit so you fail fast instead of hammering the gateway.