Skip to content
APIonWeb

Developer Docs

Rate Limits

Browse documentation

Rate limiting is a separate concern from account balance. You can have plenty of balance and still receive a 429 if you send too many requests to an endpoint too quickly — the two checks are independent.

Never assume a 429 means you're out of money, and never assume a 402 means you're being throttled — check error.code in the response body, not just the HTTP status family.

How limits are applied

  • Limits are enforced per API key, per endpoint — a burst on one key doesn't affect your other keys.
  • Both POST /v1/virtual-try-on and GET /v1/virtual-try-on/{request_id} are rate limited independently.
  • Exceeding the limit returns 429 rate_limit_exceeded — the request is rejected before processing, so it is never billed.
  • Specific limit values aren't fixed forever and may be tuned per endpoint or account over time — the reliable way to handle rate limiting is to code defensively against a 429, not to hardcode an assumed number.

The 429 response

429 Too Many Requests 
{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please slow down and try again shortly."
  }
}

Handling it

  • Treat 429 as retryable — back off and try again rather than failing the user's request outright.
  • Use exponential backoff with jitter (e.g. wait 1s, then 2s, then 4s...) instead of retrying immediately in a tight loop.
  • If your integration needs sustained high throughput, batch or queue requests on your side rather than firing them all at once.
  • For asynchronous categories, poll the status endpoint at a reasonable interval (a few seconds) rather than continuously — or better, use a webhook and avoid polling entirely.

Related: Errors for the full error code reference, and Webhooks to avoid polling-driven rate limit pressure on async jobs.