Rate limiting

Node operations share a request limit per client IP address. Requests from applications behind the same outbound IP count towards the same limit, even when they use different API keys.

The default policy is 180 requests per 60-second window. Deployment settings may change this limit; use the values returned in a rate-limit response when deciding when to retry.

Rate-limit responses

When the limit is exceeded, the API returns 429 Too Many Requests with these headers:

Retry-After tells you how many seconds to wait before retrying. X-RateLimit-Limit and X-RateLimit-Remaining describe the window, while X-RateLimit-Reset is a reset interval in seconds rather than a Unix timestamp.

These headers are returned on rate-limit errors. Do not rely on receiving them with every successful request.

View response headers

Use curl -i to include response headers when inspecting a request.

Handle throttling

Wait at least the Retry-After interval before retrying, and add a small random delay when multiple workers share an IP. Limit concurrent requests and avoid tight polling loops during node provisioning or updates.

For network failures and other transient errors, use bounded backoff rather than continuously retrying. See Error handling for reconciling requests whose outcome is uncertain.