API rate limits
Request budgets, public form limits, and how client addresses are selected.
The API applies global flood protection and stricter limits on selected routes.
A throttled request returns HTTP 429; pause before retrying. The global
limiter counts requests before body parsing and validation, so rejected requests
also consume its budget.
| Surface | Limit |
|---|---|
| Global flood protection | 6,000 requests per minute per selected IP |
POST /api/v3/contact | 10 requests per minute per selected IP |
POST /api/v3/privacy-requests | 3 requests per hour per selected IP |
| Rate-limited sign-in, signup, password reset, and mobile authentication routes | 5 requests per 15 seconds per selected IP |
POST /api/v3/desktop/wake | 5 requests per minute per selected IP |
| Workflow trigger and run-stream routes | 60 requests per minute per authenticated user |
OAuth has separate endpoint budgets.
Client addresses
Header-based limits accept valid IPv4 and IPv6 addresses. They normally use the
first X-Forwarded-For entry if valid, then fall back to a valid X-Real-IP.
Privacy requests prefer a valid X-Real-IP; only when it is missing or invalid
do they use the shared first-entry forwarding-header rule. Missing or malformed
addresses share the route's fallback budget instead of creating a new budget
for each invalid header value.
OAuth and desktop wake prefer the connection's IP when available, so clients behind the same proxy connection address can share a budget. Workflow trigger and run-stream limits prefer the authenticated user ID.
Address validation checks syntax, not authenticity. Forwarding headers must be handled according to the deployment's proxy trust configuration.