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:
| Header | Meaning |
|---|---|
Retry-After | Seconds to wait before retrying |
X-RateLimit-Limit | Request limit for the window |
X-RateLimit-Remaining | Remaining requests; 0 when limited |
X-RateLimit-Reset | Reset interval in seconds, not a Unix timestamp |
Example headers:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 180
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 60Example body:
{
"error": {
"code": "rate_limited",
"message": "rate limit exceeded"
}
}These headers are returned on rate-limit errors. Do not rely on receiving them with every successful request.
View response headers
curl -i "https://api.nodana.io/v1/nodes" \
-H "Authorization: Bearer YOUR_API_KEY"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.