API Response Error 429: Too Many Requests

Like most APIs, the Foundry API has a rate limit to protect system performance and reliability, and to help prevent cyber attacks. This article explains how the rate limit works and offers strategies to help you manage it effectively.

What is the rate limit?

Foundry allows up to 200 requests per rolling 60 seconds. If your integration exceeds this limit, Foundry will return a 429 HTTP status code.

The limit applies to all API accounts within your organization combined. For example, if you have three API accounts, their requests are counted together toward the 200-request limit. 

When you exceed the rate Limit

Exceeding the rate limit doesn’t mean your integration has failed. It just means you need to slow down and retry the request.

If your integration continues to send too many requests and triggers repeated 429 errors, Foundry may disable your API credentials to protect against potential denial-of-service attacks or runaway processes.

If this happens often, consider adding a throttling mechanism to your code. Track how many requests you’ve made in the past 60 seconds, and slow down (pause or sleep threads) as you approach the limit.

Avoid unnecessary requests

Don’t send the same request repeatedly for data that rarely changes—like Custom Categories or Locations. Instead, use a single GET request to retrieve all the data you need, rather than making multiple smaller requests.

Use bulk operations

If you're updating learner categories one at a time, switch to using the bulk label operation at admin/bulk_actions/category. This can significantly reduce the number of requests you need to send.

Implement retries with exponential backoff

• Even with optimized requests, you might still hit the rate limit—especially when adding or updating many learners at once.

  When you get a 429 response, the request wasn’t processed and is safe to retry. Use exponential backoff to retry responsibly:

  • Pause for 1 second after the first 429.
  • If you get another 429, pause for 2 seconds.
  • Then 4 seconds, then 8, and so on.

  Here are some helpful resources on implementing exponential backoff:

  • https://cloud.google.com/iot/docs/how-tos/exponential-backoff
  • https://docs.aws.amazon.com/general/latest/gr/api-retries.html
  • https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/implement-retries-exponential-backoff

Contact us for help

If you’ve followed these best practices but still receive frequent 429 errors, contact our Support team and share your use case details so we can help troubleshoot further.