rate_limited

HTTP 429. Renders were started faster than this key is allowed to start them. Nothing about the request itself is wrong — wait out Retry-After and send it again.

429 Too Many Requests

{
  "error": {
    "type": "rate_limited",
    "message": "Rate limit of 60 renders per 60 seconds reached. Retry in 23 s.",
    "docs_url": "https://galleyrender.com/docs/errors/rate_limited",
    "details": {
      "limit": 60,
      "window_seconds": 60,
      "retry_after_seconds": 23,
      "scope": "api_key",
      "next_step": "Wait for `retry_after_seconds`, then retry with exponential backoff and jitter. To push more volume in one call, use POST /v1/render/batch — 50 renders per request.",
      "raise_limit_url": "https://galleyrender.com/docs/errors/rate_limited"
    }
  }
}

Every 429 carries these headers:

Header	Meaning
Retry-After	Seconds until the window resets. The same number as details.retry_after_seconds.
X-RateLimit-Limit	Renders allowed per window.
X-RateLimit-Remaining	Renders left in this window. 0 on a 429.
X-RateLimit-Reset	Seconds until the window resets.

The first three are on successful render responses too, so you can slow down before you are refused rather than after.

The limit

Renders started per minute, counted per API key — a key that runs away cannot starve the other keys on the same account.

Plan	Renders per minute
Free, and keyless trials	60
Pay as you go, Starter, Growth, Scale	600

It is a fixed window, so the count resets on the minute rather than sliding. Only the endpoints that start renders are limited: POST /v1/render and POST /v1/render/batch. Reading a render back, listing templates, validating a payload and checking usage are not.

A batch costs one unit per item. POST /v1/render/batch with 50 renders spends 50, so the endpoint is a way to save round trips, not a way around the limit.

Note

This is separate from your free-tier allowance and spend cap, which count renders per month and answer 402. A 429 says “not this fast”; a 402 says “not any more this month”.

Why this happens

Something is rendering faster than the plan allows — usually a loop with no backoff, or a fan-out that starts every render at once. It is not about the contents of the request: the same call a second later may well succeed.

Note also that a 429 can arrive from something in front of the service — a proxy or a CDN — in which case the body may not match the envelope above. Treat any 429 as this type.

How to fix it

1. Respect Retry-After. It is always present and always in seconds.
2. Back off exponentially, with jitter. Retrying on a fixed interval across many workers re-synchronises them into the next burst.
3. Reduce concurrency rather than retrying harder. The render pool is bounded anyway, so concurrency above the limit buys nothing but 429s.
4. Batch. POST /v1/render/batch takes 50 renders in one request.
5. Watch the headers. X-RateLimit-Remaining on a successful response tells you how close you are before anything is refused.

If your workload genuinely needs a higher ceiling, the limit is stored per account and can be raised — ask through the dashboard or support@galleyrender.com.

Does retrying help?

Yes, after a delay — this is one of the few types where retrying is the correct response. Do not retry immediately or in a tight loop.