I’m working with a Zapier workflow where I have a scheduled trigger connected to a Code by Zapier action step. My goal is to make two HTTP calls within the code action - first retrieve data from one endpoint using GET, then send that data to another endpoint with POST. The problem I’m running into is performance issues. When I try using the fetch function for these requests, just the initial GET request is taking around 900 milliseconds to complete. Adding a second POST request on top of that pushes the total execution time over 1 second, which causes problems with Zapier’s timeout limits. Has anyone found a good way to handle multiple HTTP requests efficiently within Zapier’s Code action? Any suggestions would be helpful.
maybe try using Promise.all for your fetch calls. it lets them run at the same time n helps with total time. that way ur first GET and second POST happen together, reducing overall wait.
I’ve hit this same timeout problem with Zapier Code actions. Here’s what fixed it for me: add proper error handling and clean up your requests. Check if you’re sending headers you don’t need, or if those endpoints are just slow by nature. Half the time it’s the external APIs causing the delay, not your code. Add timeout parameters to your fetch calls and ask yourself - do both requests really need to run one after the other? If the POST doesn’t need the GET response, run them at the same time. Also look at shrinking your payload or using query parameters better. When a single GET takes 900ms, that screams external service bottleneck, not your code.
Sequential HTTP requests in Zapier Code actions are definitely a bottleneck. Had the same timeout issues - splitting the workflow worked way better than tweaking code. Don’t cram both requests into one Code action. Use the first Code action for your GET request, then pass that data to a second HTTP step or another Code action for the POST. Each request gets the full timeout window and debugging becomes much easier. Zapier handles data passing between steps really well, so you avoid the compounding delay mess. The extra steps add minimal overhead compared to constantly hitting timeout limits.