Rye’s official SDKs handle rate limits for you out of the box. They read the
RateLimit headers, retry 429s with backoff, and surface non-retriable errors. If you’re using an SDK, you generally don’t need to write any of the handling described below.Limits at a glance
Rate limits are scoped per account. All of an account’s API keys share the same buckets. All limits below are defaults; if your use case needs more headroom, contact us before you launch to production.
A single request can count against more than one bucket. Creating a checkout intent, for example, draws from the mutations/sec bucket, the intents/day bucket, and the concurrent-agents cap.
Response headers
Every response includes IETF draft-8RateLimit headers so you can pace your client without trial-and-error:
RateLimit-Policy: the configured limit and window for the bucket the request was charged to (e.g."default";q=10;w=1).RateLimit: your remaining quota and seconds until the window resets (e.g."default";r=7;t=1).
HTTP 429 Too Many Requests with a JSON body:
Handling 429s
- Read the headers. When
RateLimit’sr=(remaining) reaches 0, pause new requests untilt=seconds have elapsed. - Back off on 429. Retry with exponential backoff plus jitter. A first retry after 1–2 seconds is usually enough for the per-second buckets.
- Treat the daily and concurrent-agent limits as soft ceilings on your throughput, not as transient errors — retrying immediately won’t help. Queue work and drain it as quota frees up, or request a higher limit.

