429 errors – rate limiting

	Note
	Boost.space IntegratorPart of the Boost.space system, where you can create your connections and automate your processes. follows the standard error codes and their definitions. Note that it is possible that the third party may not fully comply with the standard.

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 scenarioA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive. 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 with an instant trigger (for example, a Webhook module), enable sequential processing in scenario settings. With , the module processes incoming data one by one in the order they arrive.

Otherwise, skip this step.

Note

If a scenario has and sequential processing enabled, Boost.space Integrator 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.
Enable incomplete executions in the scenario settings. Boost.space Integrator will save bundles that caused the error.

For example, if you would use the WebhookA webhook is a way for an app to send real-time information to a specific URL in response to certain events or triggers. 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:

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 IteratorWhen creating a scenario, use an iterator to divide one bundle into smaller separate bundles. Subsequent modules then process the bundles separately. One common use is when automatically uploading email attachments to a cloud drive. You can find iterators under the Flow control of the tools section. module, you can use the meta-variable BundleA bundle is a chunk of data and the basic unit for use with modules. A bundle consists of items, similar to how a bag may contain separate, individual items. order position.
You can convert incoming bundles to an arrayWithin a bundle, data items of the same type are sometimes in an array. You can find an array by looking at the details of a bundle. Depending on the details of your scenario, you can map other modules to a specific item in an array or use iterators and aggregators to manipulate your data into other formats. When mapping,... with the Array aggregatorWhen designing a scenario, use an array aggregator to merge multiple bundles into one single bundle. This may be necessary to format data properly for subsequent modules. The array aggregator also lets you define your target data structure. module and then use the Iterator.

You can use the Increment functionFunctions you can use in Boost.space Integrator - create, update, delete, get, search. module.

	Caution
	Every bundle that goes through the Increment function module uses 1 operationAn operation is a task performed by module.. If you need to count a lot of bundles, consider a different option.

In the following example, we create a scenario with the Array aggregatorYou can use a table aggregator to create a table from multiple bundles. The table aggregator merges values based on your specified column and row parameters and outputs into a single bundle. One possible use is compiling blog posts or emails into a single email summary. and Iterator modules, because it’s universal and uses just a few operationsAn operation is a task performed by module..

Set up your scenario. In our example, we will use the Data StoreA data store is a built-in database in Boost.space Integrator. You can use data stores to store data from scenarios or transfer data between individual scenarios or scenario runs. Your account includes data stores, so you do not have to register at a third-party service. > Search Records and HTTP > Make a request modules. The Make a request module returns 429 errors.
Add a routerA router allows you to add new routes to a scenario so you can branch your flow into several routes and process the data within each route differently. before the HTTP > Make a request module.
Create a route with the router. This route will be your “delay route.”
Add the Array aggregatorAn aggregator is a type of module that allows you to merge multiple bundles into one single bundle. Aggregators are useful in making data readable for certain modules or generating meaningful output. Boost.space Integrator offers:
Array aggregator
Numerical aggregator
Table aggregator
Text 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.
Add the Iterator module after the Array aggregator. Iterate the array output from the aggregator.
Add the Sleep module after the iterator. Set the time delay.
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:
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:

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.