Best answer

API Call Retry

  • 13 January 2020
  • 8 replies

Userlevel 3

We have an endpoint in our API that we are using with Zapier that if it takes to long requires a retry after a few seconds. How could we implement this flow?


Best answer by PaulKortman 14 January 2020, 22:09

View original

This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

8 replies

Userlevel 7
Badge +10

Are you using a webhook within a zap, or are you building an application/integration on the Zapier platform?

Userlevel 3

We are building an application/integration on the Zapier platform.

Userlevel 7
Badge +10

Then this thread should be moved over to the Developer Discussion I think @Danvers can help us with that.

Are you using the CLI (Code mode) or the GUI (form based) and do you know how promises work within javascript?

Screenshot 2020-01-13 08.31.15.pngOnce you switch to code mode you can edit the Javascript.

Screenshot 2020-01-13 08.32.47.png

I'm not an advanced developer, but basically from my understanding you could build a "while" loop or an "if-then-else" statement with the promise of a result from an API endpoint. It's all javascript, so if you can build it in Javascript then you can build it on the Zapier platform.

Userlevel 4
Badge +4

@jarrett The timeout for a Zapier app process is 30 seconds, so a couple seconds to return a request shouldn't be an issue.

Waiting for a promise in the code step like @PaulKortman suggested should be adequate.

Post your actual code here if you get stuck and we can help.

Userlevel 3

@BowTieBots the problem is our API request could take over 30 seconds. What we usually tell our users to do is to retry the request in a few seconds until it comes back. Sometimes it could take 2-3 minutes for a slower request. How would we best handle this?

Userlevel 7
Badge +10

@jarrett That's poor API behavior. In cases like that where it will take some processing time API's typically are built to ask for a callback URL, when the processing is done it then notifies the callback URL.

Are you in charge of the API, can you make changes like that so it has a callback URL which can be another Zap with a webhook?

Userlevel 3

@PaulKortman I understand your thought process. We could consider that. When the API initially was created it was not a large priority. 99% of requests come back in under 1 second. It's just a rare situation we have to deal with. I guess we can consider doing a callback to make Zapier run smoother in the future.

Userlevel 7
Badge +10

@jarrett take a look at the following examples:

Webhooks Best Practices | Stripe "If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Stripe sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a 2xx status code) is separate of any other logic you do for that event."

Webhooks by Zapier - Integration Help & Support | Zapier "For High Availability and High Throughput reasons - we always return a success message with a payload of debugging information when collecting a webhook - regardless of whether there is a Zap behind the webhook or if it is paused or not. The only way to know if a URL is live is to visit the editor and look at the URL (which never changes for a Zap). There is no way to customize the response to the request you send to the Catch Hook URL, as the response is sent before the Zap triggers and runs on the webhook request."

I really think you need to change how your API handles requests. Even in these semi-rare situations.

But that aside, you can develop the javascript code to keep retrying, but if a specific api call will always take longer than 30 seconds it will never complete.