Rate Limits — Wahlu API Docs

Default limits

The Wahlu API allows 100 requests per minute per API key. This limit applies across all endpoints, and each key has its own budget, even when several keys call from the same server.

Requests without a valid API key, including the public platform capabilities endpoint, share a budget of 100 requests per minute per client IP address.

Rate limit headers

Every API response includes headers that tell you your current rate limit status:

Parameter	Type	Description
`X-RateLimit-Limit`	integer	The maximum number of requests allowed per minute.
`X-RateLimit-Remaining`	integer	The number of requests remaining in the current window.
`X-RateLimit-Reset`	integer	Seconds until the current window resets.

Example response headers

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 42

Exceeding the limit

When you exceed the rate limit, the API returns a 429 Too Many Requests response. The response body includes a RATE_LIMITED error code and the Retry-After header tells you how many seconds to wait.

429 response

HTTP/1.1 429 Too Many Requests
Retry-After: 23
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 23

{
  "success": false,
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests. Please slow down.",
    "status": 429,
    "retryable": true,
    "request_id": "req_..."
  }
}

Best practices

Check the headers — Monitor X-RateLimit-Remaining and slow down before hitting zero.
Implement exponential back-off — When you receive a 429, wait for the Retry-After duration, then gradually increase delays on repeated failures.
Follow the bounded workflow — Reuse returned IDs and links, read Media and Schedule status once, and do not hide a polling loop.
Revalidate capabilities — Cache platform capabilities and use their ETag for a conditional request when the data does not change frequently.