Hi @boinlabs
There is no way to specify the number of retries with the z.errors.ThrottledError
- however the number of retries would not be infinite.
A high volume of errors can cause a Zap to get turned off. More info on how throttling applies and how it is shown to the user can be found here: https://platform.zapier.com/docs/constraints#throttling-your-api
Note that throttling applies per individual run per user. So if a Zap action is being attempted multiple times consecutively (if the trigger on that Zap fires many times for example), each will be throttled independent of the others.
It is an option to use the custom error handling method z.errors.Error
: https://github.com/zapier/zapier-platform/blob/main/packages/cli/README.md#general-errors so the Zap throws an error in response to a 429. That would prevent any retries all together but this may not be desirable for your users.
If the concern is too many attempts to retry all at once hitting the API limit and repeatedly receiving a 429; one idea some partners have tried is to implement your own "jitter", if you do want Zaps to be able to retry, but not all at once. That could look something like this:
throw new z.errors.ThrottledError('message here', 60 + Math.floor(Math.random() * 60))
and make it so that the retry would occur between 1 and 2 minutes from the time the 429 error is received, and you can adjust those numbers as needed.