Rate limits
Rate limits protect studios and members from abusive or accidental traffic. Build clients so a temporary limit is handled without data loss.
Current reference status
The current Storefront and Management OpenAPI bundles do not declare a 429 response or rate-limit headers on any operation. Treat limits as a protective boundary that may be added additively, and handle 429 Problem responses if they appear.
Client behavior
If a request is rate-limited, pause that integration and retry later. Use
exponential backoff with jitter. For writes, keep the same Idempotency-Key while
retrying the same action so the retry cannot apply twice.
Recommended backoff:
| Attempt | Delay before retry |
|---|---|
| 1 | 1-2 seconds |
| 2 | 2-5 seconds |
| 3 | 5-15 seconds |
| Later | Cap at 60 seconds, then alert |
Do not fan out retries across many workers with the same key. That turns a temporary limit into a larger incident.