429 errors – rate limiting

App modules return 429 errors 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.

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.

How to handle 429 errors

You can use the following strategies to handle 429 errors:

  • 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.

 

  1. If your scenario triggers with an instant trigger (for example, a Webhook module), enable sequential processing in scenario settings. With sequential processing, the trigger module processes incoming data one by one in the order they arrive.
    429-error-scenario-settings.png

    Otherwise, skip this step.

    [Note] Note
    If a scenario has incomplete executions and sequential processing enabled, Boost.space Integrator pauses the scenario until the incomplete executions are processed to keep the order of incoming data.
  2. 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.
  3. 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.
  4. Enable incomplete executions in the scenario settings. Boost.space Integrator will save bundles that caused the error.

For example, if you would use the Webhook trigger to send data with the HTTP module, but the HTTP module is causing errors, your scenario and scenario settings with error handling would look like this:

error-429-example-scenario.png
429-error-scenario-settings.png

Advanced 429 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 429 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] 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.

 

  1. 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 429 errors.
  2. Add a router before the HTTP > Make a request module.
  3. Create a route with the router. This route will be your “delay route.”
  4. Add the Array aggregator to the “delay route.”

     

    1. Set the Source module to the Search Records module.
    2. Select any data from the data store to create the array. You won’t use the data in the delay route.
  5. Add the Iterator module after the Array aggregator. Iterate the array output from the aggregator.
  6. Add the Sleep module after the iterator. Set the time delay.
  7. Create a filter between the Iterator and Sleep modules.

     

    1. Set the filter condition to use the Bundle order position variable output from the Iterator module.
    2. Use the mod mathematic operator to set the frequency of the delay.
    3. 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:

    429-error-delay-frequency.png
  8. Order the router routes to run the “delay route” before the Make a request module.You can add the Break error handler for the Make a request module too.

Our finished example scenario looks like this:

429-error-advanced-scenario.png

When you run the scenario, every 60th bundle should trigger the Sleep module delay. The setup consumes only two extra operations to count the bundles.