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 https //en wikipedia org/wiki/list of http status codes {{product name}} 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 https //developers google com/sheets/api/limits for the google sheets app docid\ nefhj6m7mksbmjx w9ip when a module returns the types of errors docid\ n4w0yaeop7a a4vfw ebp and you don't use any error handling, {{product name}} act depending on the following attributes {{scenario singular lowercase}} scheduling enabling of the incomplete executions incomplete executions disabled incomplete executions enabled scheduled {{scenario singular lowercase}} {{product name}} pauses the scheduling of the scenario for 20 minutes {{product name}} doesn't rerun the scenario {{product name}} pauses the scheduling of the scenario for 20 minutes {{product name}} retries the incomplete execution with the incomplete execution exponential backoff docid\ le2snkujgl9uzqfm 0v3i instant {{scenario singular lowercase}} {{product name}} reruns the incomplete execution with the {{scenario singular lowercase}} exponential backoff docid\ le2snkujgl9uzqfm 0v3i {{product name}} retries the incomplete execution with the incomplete execution exponential backoff docid\ le2snkujgl9uzqfm 0v3i 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 {{scenario plural lowercase}} if your {{scenario singular lowercase}} has a third party app module that consumes a lot of operations or if you use an app module in your {{scenario plural lowercase}} 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 singular lowercase}} how to customize the handling of rate limit errors you can use the following strategies to handle the ratelimiterror add a delay with the module docid\ cwfbo7bvo3bpzcsxcaqof before the app module to delay the requests add the error handler docid\ hxe6n1fool691glswodgy to the module to handle errors and prevent turning off the {{scenario singular lowercase}} 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 singular lowercase}} triggers with an types of modules docid\ pdopibceckcbomppkplmy (for example, a webhooks docid 1yhunj8jvzyxip9cf3ps1 ), consider enabling scenario settings docid\ evar6qlowv4yyuneyv 00 in {{scenario singular lowercase}} settings with sequential processing, the trigger module processes incoming data one by one in the order they arrive otherwise, skip this step if a {{scenario singular lowercase}} has incomplete executions and sequential processing enabled, {{product name}} pauses the {{scenario singular lowercase}} 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 fixing rate limit errors docid\ oxgtalgvur0yzkn ux9wk 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 singular lowercase}} flow again after another delay set the number of retries and the retry delay in the handler settings enable incomplete executions docid 6zznn7v35herrcjfccp9q in the {{scenario singular lowercase}} settings {{product name}} 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 {{scenario singular lowercase}} and {{scenario singular lowercase}} 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 singular lowercase}} 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 singular lowercase}} 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 {{scenario singular lowercase}} with the array aggregator and iterator modules, because it's universal and uses just a few operations set up your {{scenario singular lowercase}} 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 singular lowercase}} , every 60th bundle triggers the sleep module delay the setup consumes only two extra operations to count the bundles