Skip to content
WP EngineDocumentation

Rate limits

Rate limits are enforced at the edge load balancer, before a request reaches the API. When you exceed a limit, you get HTTP 429.

Current limits (AI Beta)

Section titled “Current limits (AI Beta)”
Bucket Limit
Per Authorization value (any auth) 600 req / 60 s
Per IP (unauthenticated) 60 req / 60 s

These limits apply across the entire /v1/* surface — not per-endpoint.

The 429 response

Section titled “The 429 response”

The 429 response body is generated by the load balancer as a short HTML page rather than the standard JSON error envelope, and there is no Retry-After header:

HTTP/2 429
content-type: text/html; charset=UTF-8


<!doctype html>…<title>429</title>429 Too Many Requests

A 429 can also come from the model provider when it is busy. That one uses the standard error envelope with "type": "rate_limit_error". It means the model is busy, not that you hit your limit, but you handle it the same way.

Section titled “Recommended client behavior”
  1. Catch 429 responses explicitly.
  2. Back off exponentially with jitter — e.g. start at 1 s, double on each retry up to a 30 s ceiling, plus 0–500 ms jitter.
  3. Cap total retries at a number that matches your SLO — typically 3 to 5 attempts.
  4. Do not retry on 400, 401, 402, 403, or 404. Those will not succeed on a second attempt.

Streaming and long requests

Section titled “Streaming and long requests”

Streaming chat completions count as a single request against the rate limit regardless of duration. If you exceed the limit while a stream is in progress, the in-flight stream completes; only the next request is throttled.

Calls to the model provider are also subject to a server-side timeout (currently 110 seconds). A request that exceeds it returns 504 with "type": "timeout_error" rather than 429. For a streaming request, the timeout covers the wait for the stream to start, not its full duration.

Last updated: