Rate limits protect the renderer from noisy neighbours. They are counted per API key in a fixed one-minute window: the allowance resets in full at the top of each clock minute rather than refilling gradually.

Default limits

The limit comes from your account plan, not from the key. There is one key type and every key on the same account gets the same allowance.

Paid plans — 60 requests / minute per key. Measured, not aspirational: this page said 120 until 2026-08-03, when a check against the running API found every environment answering RateLimit-Limit: 60. Treat the header on your own response as the authority.
Free — 20 requests / minute per key. Size load tests on the plan you will actually run on.
Nobody gets “unlimited”. The whole system measures ~142 documents / minute, so one key at 60/min is already a large share of it — we publish the real ceiling instead of a number we would have to walk back.
No hard daily cap — credit balance is the effective ceiling.
Need higher throughput? Email hi@pixldocs.com to raise your key's limit.

Headers on every response

Pace your client off these rather than waiting to be refused. They describe your key's limit, and are readable cross-origin.

http

RateLimit-Policy: 60;w=60
RateLimit-Limit: 60
RateLimit-Remaining: 38
RateLimit-Reset: 24        # seconds until the window resets

Response when limited

A 429 also carries Retry-After in seconds. Sleep for it — retrying sooner lands in the same window and is refused again. limit_per_min in the body is your key's real ceiling on the environment you just called, which is the number to log when a limit surprises you.

http

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 24
RateLimit-Remaining: 0

{
  "error": "rate_limited",
  "limit_per_min": 60,
  "retry_after": 24
}

A separate coarse per-IP ceiling guards the edge against floods. It is far above the per-key limit and emits no RateLimit-* headers — if you are being limited, it is almost always the per-key limit above. If you do trip it, the response is a 429 with "scope": "ip" in the body and a Retry-After header, so the same backoff handles both.

For batch workloads, prefer POST /v1/renders/batch (100 jobs / 1 request) over 100 calls to /v1/render. Batch counts as a single request.