Rate limiting
The Indeed Flex Reporting API enforces rate limits to ensure fair usage and protect service availability. Requests that exceed these limits receive a 429 Too Many Requests response.
Limits
| Scope | Limit | Window | Keyed on |
|---|---|---|---|
Reporting endpoints (/v1/reporting/...) | 100 requests | 60 seconds | Access token |
The reporting endpoints are governed only by the per-access-token limit above. Each unique OAuth token has its own independent allowance of 100 requests per 60 seconds.
The general client API limit of 4 requests per 10 seconds per IP address does not apply to the /v1/reporting/... reporting endpoints. You do not need to spread reporting requests across IP addresses to stay within the limit -- only the per-token allowance matters.
Handling rate limit responses
When you exceed the rate limit, the API returns a 429 status code with a Retry-After header indicating how long to wait before making another request. Your integration should handle this gracefully:
- Check the
Retry-Afterheader. The response includes aRetry-Aftervalue in seconds. Wait at least this long before retrying. - Use exponential backoff. For repeated
429responses, increase the wait time between retries (e.g. 1s, 2s, 4s, 8s) to avoid further throttling. - Do not retry immediately. Sending requests in a tight loop after receiving a
429will extend the time you remain throttled.
Best practices
- Cache responses where possible. If your reporting data does not change frequently, avoid making repeated calls for the same data within a short period.
- Batch date ranges into fewer, larger requests rather than many small ones. For example, request a full month of shift fulfilment data in one call rather than making 30 daily requests.
- Spread requests over time. If you need to make many calls (e.g. for multiple employers or endpoints), distribute them evenly rather than sending them all at once.
- Monitor your usage. Track the number of requests your integration makes and ensure it stays comfortably within the limit.