Avoiding "Too Many Requests" Errors
Two common scenarios where API users exceed the rate limit is through sustained high frequency requests, or a sudden burst of requests. You might want to create a long list of Meter Entries, for example. Or maybe you're downloading many pages of Work Orders for analysis or reporting. The best way to avoid the rate limit is to design your system with the rate limit in mind. You can leverage the following resources to avoid common causes of rate limiting.
Use the Bulk API
API users often want to create Location Entries or Meter Entries at a regular interval. Submitting Entries for multiple assets at high frequency can easily exceed the rate limit.
If you anticipate sending more than 20 requests per minute, we recommend using our Bulk API to send a single request to create up to 100 supported records at a time.
API users will often encounter rate limiting when many requests are made for multiple pages of records in rapid succession. For example, you may only be interested in Meter Entries for a few specific vehicles, or only Fuel Entries from this month. The Filtering and Sorting guide has more information on how to reduce the amount of data you're fetching.
How should a 429 response be handled?
The best way to handle a 429 response is to sleep for the number of seconds in the
Retry-After header, and then proceed. This can be done in many ways depending on your development environment, but here's a brief example of one way to do this in Ruby:
response = Net::HTTP.get_response(url)
break unless response.code === "429"