Pre-release — contact your Fortary account team for access.
Rate-limit headers
Every response from a rate-limited endpoint carries these headers, so your client can stay within budget without guessing:| Header | Meaning |
|---|---|
X-RateLimit-Limit | The maximum number of requests allowed in the current window. |
X-RateLimit-Remaining | How many requests remain in the current window. |
X-RateLimit-Reset | When the current window resets, as a Unix timestamp (seconds). |
429 Too Many Requests and a Retry-After header giving the number of seconds to wait before retrying.
Handling limits
Watch the headers
Track
X-RateLimit-Remaining. As it approaches zero, slow your request rate rather than waiting for a 429.Respect Retry-After on 429
If you receive a
429, wait the number of seconds in Retry-After before retrying — don’t retry immediately.Back off and retry for transient errors
For
429, 500, and 503, retry with exponential backoff, adding a small random delay (jitter) so simultaneous clients don’t all retry at the same instant. 503 responses also include a Retry-After header. Don’t retry 400/401/403/404/422 — those won’t succeed on retry without a change to the request or credential.Limit values
The specific request limits for your organization are shared when your organization is granted access. They aren’t published here while the API is in pre-release. Build your client to read the rate-limit headers above rather than hard-coding a fixed rate, and it will adapt to whatever limits apply.