Rate limits

The APIs are rate-limited to keep the platform responsive. Limits are applied per client and enforced at the service edge.

Reading the limit

Every response carries the current limit state — always trust the headers over any hard-coded assumption, since limits can be tuned per environment:

Header	Meaning
x-ratelimit-limit	Max requests allowed in the current window.
x-ratelimit-remaining	Requests remaining in the current window.
x-ratelimit-reset	Seconds until the window resets.

The default policy is on the order of 100 requests per minute; the headers tell you the exact values in force.

When you’re limited

Exceeding the limit returns 429 with the standard error envelope and a Retry-After header (seconds to wait):

{
  "statusCode": 429,
  "code": "RATE_LIMITED",
  "error": "Too Many Requests",
  "message": "Rate limit exceeded, retry later."
}

Backing off

• Respect Retry-After. Wait at least that long before retrying.
• Use exponential backoff with jitter for repeated 429s to avoid thundering-herd retries.
• Stay under the limit proactively by watching x-ratelimit-remaining and smoothing bursts.
• Batch and cache where you can — for example, read a release once and reuse it rather than re-fetching per product.

429 and 503 are the two statuses that are always safe to retry. See Errors & conventions for the rest.