Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

I am building a private integration that performs some complex API operations in a single Zapier Action.

Due to the complexity (number of outbound API calls it has to perform), it is possible that during the Action, the private API will exceed its throttle limits and return an error to Zapier, initiating a ThrottledError.

The Zapier docs tell us that:

If a response receives a status code of 429 and is not caught, Zapier will re-attempt the operation after a delay.

In this case, what is an “operation”? It would be great if that was the exact API call, deep inside the Action, that prompted the error, but I don’t see how Zapier would know how to get back to that exact point in the code to repeat it. So, does this mean that Zapier will restart the same Action from the beginning, with its original parameters? Or does the whole Zap repeat?

Whichever way it does this, how do other people handle this to perhaps detect where the Action was up to, and avoid repeating any API calls that had already been performed?

e.g. if the Action creates a record via the API, then has to create some additional attached records, and gets throttled on those additional records, I don’t want the Action to create the same record all over again.

Lastly, is there any way to distinguish when an Action is being re-attempted versus its initial run?

 

Thanks
Stephen

Hi @StephenB 👋

If a request receives a 429 back from your API, it would only be that request that is attempted again, not the ‘action’ or Zap run itself. So if an action contains multiple API requests within it, and only one received a 429, only that request would be attempted again. 

As you found in the documentation, you can include a retry-after header in the 429 response back to Zapier with the desired delay in seconds. If not specified, the request will be attempted after 60 seconds. 

Instead of a user’s Zap erroring and halting, this message is shown in the Zap History instead of an error while the retries are attempted: https://platform.zapier.com/docs/constraints#throttling-your-api but there wouldn’t be any value included in the request itself to indicate it is a retry - the exact same request is sent to your API again. 

If you’re seeing different behaviour than described with your integration, please open a ticket with us  from https://developer.zapier.com/contact including an example Zap run that was not retried as you’d expect. 

 

Thanks @MarinaH, that’s a big help.

A follow-up question: If there is further code following the API call that threw the exception due to the 429, I can I conclude that this code will not be run?

i.e. I can see how the API call can get repeated, as the system holds all the information required to repeat that call. However, since an exception was thrown, that would bypass whatever code (possibly additional API calls) that came after it, since I don’t think there’s any way to restart code execution right after the point where the exception was thrown.

Hope that makes sense!

I guess I just need to bear this in mind when designing the program flow. I think it will be fine if the API call was a final CREATE/UPDATE/DELETE, but if it’s a request that returns data necessary for the rest of the Action, I will have to plan accordingly.

Thanks again for your helpful response.
Stephen

Hi @StephenB 

Yes, that sounds right, though you’d want to try it out to see this in action for your specific code! If consecutive API requests within the same action require data returned from the call that received a 429, they would presumably receive a different error from your API, which would halt the Zap run. 

Whereas if the action only contained a single API request, which was throttled, and later succeeded on retry, the Zap run would proceed once that was successful and show the action as a Success. 

Terms & Conditions