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.
follows the standard error codes and their definitions. Note that it is possible that the third party may not fully comply with the standard.
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 and you don't use any error handling, act depending on the following attributes:
- scheduling
- enabling of the incomplete executions
| Incomplete executions disabled | Incomplete executions enabled |
|---|---|---|
Scheduled | pauses the scheduling of the scenario for 20 minutes. doesn't rerun the scenario. | pauses the scheduling of the scenario for 20 minutes. retries the incomplete execution with the incomplete execution backoff. |
Instant | reruns the incomplete execution with the backoff. | retries the incomplete execution with the incomplete execution backoff. |
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 .
If your has a third-party app module that consumes a lot of operations or if you use an app module in your 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 .
You can use the following strategies to handle the RateLimitError:
- 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 triggers with an instant trigger (for example, a custom webhook module), consider enabling sequential processing in settings. With sequential processing, the trigger module processes incoming data one by one in the order they arrive.
Otherwise, skip this step.
If a has incomplete executions and sequential processing enabled, pauses the 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 flow again after another delay. Set the number of retries and the retry delay in the handler settings.
Enable incomplete executions in the settings. will save bundles that caused the error.
For example, if you would use the Webhook trigger to send data with the OpenAI module, but the OpenAI module is causing errors, your and settings with error handling would look like this:
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 .
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 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.
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 with the Array aggregator and Iterator modules, because it's universal and uses just a few operations.
Set up your . 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 , every 60th bundle triggers the Sleep module delay. The setup consumes only two extra operations to count the bundles.