Fixing rate limit errors
App modules return the RateLimitError when you reach the API rate limit for the app. The rate limit is the number of requests you can send to an app over a period of time, typically over a second or a minute. The RateLimitError corresponds to the HTTP error code 429.
When you reach the app rate limit, the app will block further requests until the limiting time period passes. For example, these are the API rate limits for the Google Sheets app.
When a module returns the RateLimitError in a scheduled scenario run and you don't use any error handling, Make automatically schedules rerunning the scenario after 20 minutes.
Note
Keep in mind that a third-party app tracks the rate limiting in your account in the app. The rate limiting of the app is shared between all your scenarios.
If your scenario has a third-party app module that consumes a lot of operations or if you use an app module in your scenarios frequently, consider checking the rate-limiting of the third-party API or using the following error handling strategies preemptively to avoid frequent reruns of your scenario.
How to handle rate limit errors
You can use the following strategies to handle the RateLimitError:
Add a delay with the Sleep module before the app module to delay the requests.
Add the Break error handler to the module to handle errors and prevent turning off the scenario schedule.
Combine both of the options together.
In the following steps, we combine a delay with the Sleep module and the Break error handler to handle the error if it occurs even after the delay.
If your scenario triggers with an instant trigger (for example, a custom webhook module), consider enabling sequential processing in scenario settings. With sequential processing, the trigger module processes incoming data one by one in the order they arrive.
Otherwise, skip this step.
Note
If a scenario has incomplete executions and sequential processing enabled, Make pauses the scenario until the incomplete executions are processed to keep the order of incoming data.
Add the Sleep module before the module that is causing the error. Set the delay to fit into the number of requests in the time limit. For example, if the app is limited to 10 requests per minute, set the delay to 6 seconds.
Look into the advanced strategies if you want to have finer control over the delays.
Add the Break error handler to the module that is causing the errors.
If the Sleep module delay doesn’t prevent the error, the Break handler runs the module with the rest of the scenario flow again after another delay. Set the number of retries and the retry delay in the handler settings.
For example, if you would use the Webhook trigger to send data with the OpenAI module, but the OpenAI module is causing errors, your scenario and scenario settings with error handling would look like this:
Advanced rate limit error handling strategies
When the strategies we mentioned above don't fit your use case or don't work for you, you can find more information in the following section. Here, we share advanced approaches to handling the rate limit errors in a scenario.
Fine-tuning the Sleep delay
This strategy can help you if you want to trigger the delay after the module processes a specific number of bundles.
If the modules you use in your scenario output a value you can use to number them, you can have a "delay route." You set the frequency of the delay with a filter and the duration of the delay with the Sleep module.
Options to enumerate bundles include:
If you create bundles with an Iterator module, you can use the meta-variable Bundle order position.
You can convert incoming bundles to an array with the Array aggregator module and then use the Iterator.
You can use the Increment function module.
Caution
Every bundle that goes through the Increment function module uses 1 operation. If you need to count a lot of bundles, consider a different option.
In the following example, we create a scenario with the Array aggregator and Iterator modules, because it's universal and uses just a few operations.
Set up your scenario. In our example, we will use the Data Store > Search Records and HTTP > Make a request modules. The Make a request module returns the
RateLimitError.Add the Array aggregator after the Data Store > Search Records module.
Set the Source module to the Search Records module.
Select any data from the data store to create the array.
Add the Iterator module after the Array aggregator. Iterate the array output from the aggregator.
With the Array aggregator -> Iterator flow, we create an array that we iterate to get the Bundle order position meta-variable in the Iterator output. In the next steps, we use this variable to delay the Make a request module to avoid the
RateLimitError.Add a Router after the Iterator module.
Add the Sleep module to the first route from the router. This route will be your "delay route.". Set the time delay in the Sleep module settings.
Create a filter between the Router and Sleep modules.
Set the filter condition to use the Bundle order position variable output from the Iterator module.
Use the mod mathematic operator to set the frequency of the delay.
Set the filter operator to Numeric: Equals to and the other number to 0.
For example, the following filter triggers the delay with every 60th bundle:
After processing 60 bundles, the Sleep delay triggers. If the app API has a rate limit of 60 requests per second, adding a 1 second delay with the Sleep module prevents the
RateLimitError.Add the HTTP > Make a request module to the second route from the Router
You can add the Break error handler for the Make a request module too.
Our finished example scenario looks like this:
When you run the scenario, every 60th bundle triggers the Sleep module delay. The setup consumes only two extra operations to count the bundles.