SailPoint Rate limits
How SailPoint API rate limits work and how to stay within them.
SailPoint enforces per-tenant rate limits; exceeding them returns HTTP 429, and clients should back off and retry using the response headers.
- Limits are enforced per tenant
- 429 Too Many Requests signals throttling
- Respect Retry-After / limit headers
- Batch and paginate to reduce calls
SailPoint enforces rate limits to protect the platform from overload. When a client exceeds its allowance the API responds with 429 Too Many Requests, and well-behaved clients back off and retry using the information in the response headers. Designing for rate limits from the start avoids brittle, failure-prone integrations.
How rate limiting works
Limits are applied per tenant over a time window. Responses include headers describing your remaining quota and, on a 429, how long to wait before retrying (for example a Retry-After header). Treat these headers as the source of truth rather than guessing.
Reacting to 429 correctly
- Honor
Retry-Afterwhen present, wait exactly that long before retrying. - Use exponential backoff with jitter for repeated 429s, so many clients do not retry in lockstep.
- Never hot-loop retries, that amplifies the overload and can extend throttling.
Reducing how often you hit limits
- Filter server-side so you request only needed records.
- Paginate with sensible page sizes rather than many tiny calls.
- Use bulk endpoints where available.
- Avoid bursts of parallel calls, spread the work.
Common pitfalls
- Bursty parallelism hammering the API and triggering 429s.
- Ignoring
Retry-Afterand retrying immediately. - No backoff, turning a brief limit into a sustained failure.