Skip to content
WP EngineDocumentation

Rate limits

The edge load balancer enforces rate limits before a request reaches the API. When you exceed a limit, you get HTTP 429.

Bucket Limit
Per Authorization value (any auth) 600 req / 60 s
Per Internet Protocol (IP) address (unauthenticated) 60 req / 60 s

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

The load balancer generates the 429 response body as a short HTML page, not the standard JSON error envelope. The response has 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’s busy. That response uses the standard error envelope with "type": "rate_limit_error". It means the model is busy, not that you hit your limit. Handle it the same way.

  1. Catch 429 responses explicitly.
  2. Back off exponentially with jitter. For example, start at 1 s, double the delay on each retry up to a 30 s ceiling, and add 0–500 ms of jitter.
  3. Cap total retries at a number that matches your service-level objective (SLO), typically 3 to 5 attempts.
  4. Don’t retry on 400, 401, 402, 403, 404, or 413. These responses don’t succeed on a second attempt. The exception is a 403 with "type": "billing_account_pending", which clears once the account’s billing setup finishes.

A streaming chat completion counts as a single request against the rate limit, regardless of its duration. If you exceed the limit while a stream is in progress, the in-flight stream completes. The load balancer throttles only the next request.

The gateway also applies a server-side timeout to each call to the model provider, currently 110 seconds. It retries a call that times out up to three more times. If every attempt times out, the gateway returns 504 with "type": "timeout_error", not 429. For a streaming request, the timeout covers the wait for the stream to start, not its full duration.


Last updated: