Rate Limiting

By default, Degreed limits a single API client to 200 requests per minute (rpm). Some organizations may be assigned custom rate limits based on their integration requirements. When custom limits are configured, the rate limit response headers reflect the limits currently applied to your API client.

If you exceed your assigned rate limit, the API returns a 429 Too Many Requests response along with a Retry-After header that specifies how long to wait before making another request.

Rate Limit Headers

The following is an example response with rate limiting headers:

HTTP/1.1 200 OK
X-Rate-Limit-Limit: 1m
X-Rate-Limit-Remaining: 69
X-Rate-Limit-Reset: 2021-10-26T20:39:22.1494434Z

Handling Rate Limit Errors

When a 429 Too Many Requests response is returned:

• Read and honor the value provided in the Retry-After header before retrying the request.
• Avoid immediately retrying failed requests, as doing so may extend the period of rate limiting.
• For automated integrations, implement retry logic with exponential backoff.
• Monitor the X-Rate-Limit-Remaining header and proactively throttle requests as the limit is approached.

Best Practices

To avoid common causes of rate limiting issues:

• Use the ?limit parameter to increase the number of resources returned per request.
• Use filter parameters to retrieve only the data that has changed rather than requesting complete datasets.
• Process large, non-time-sensitive jobs during off-hours and at a controlled rate.
• Monitor rate limit headers to optimize request volume and avoid exceeding limits.

For example, some endpoints support filtering by date to retrieve only newly created or updated records:

GET https://betatest.degreed.com/api/v2/content?filter%5Bst

Requesting Higher Rate Limits

If your integration requires a higher rate limit than the default allocation, contact your Degreed Technical Solutions Specialist. Degreed will review the use case and determine whether a custom rate limit can be applied.