1. What is this issue?
When a flow has multiple REST API nodes firing one after another in the same turn (no user interaction in between), the whole chain can silently fail even if each individual API responds within our per-node 30-second timeout.
This can happen in any flow that chains a few slow, sequential external API calls — for example, one API that generates an image, another that generates a PDF, followed by a Store to Variable block. Each API on its own might be well within 30 seconds, but the flow still doesn't behave as expected, and nothing shows up in
2. Why does it happen?
Each REST API node has its own 30-second timeout — but that's not the only limit in play.
There's also a top-level 60-second cutoff for the entire message-processing turn. This 60-second budget covers everything that happens after the user's message comes in and before our reply goes out:
All REST API calls in that turn
Store to Variable blocks
Sending the outgoing WhatsApp message via Meta
So even if each API is individually fast, if you chain several of them (plus the surrounding blocks) in a single turn, their times add up and can blow past the 60-second ceiling. When that happens, the whole turn gets cut off — not just the slow node — which is why it doesn't land in the Failure node either. Right now the platform doesn't distinguish "this one node timed out" from "the whole turn ran out of time."
Example scenario — two APIs plus a delay block, all in one turn:
Block | Time taken |
REST API #1 (Image Creation) | ~18-21s |
REST API #2 (PDF Creation) | ~21-22s |
Custom Delay | ~15s |
Total | ~55-58s |
That leaves almost no room for the rest of the turn (Store to Variable, sending the WhatsApp reply, etc.), so it tips over 60s.
3. How to fix it — breaking the flow
The fix is to not run all the API calls in one uninterrupted turn. Split the chain by inserting a message or user-interaction node between the API calls. Each time the flow waits for the user to reply or click a button, that counts as the end of one turn and the start of a new one — which resets the 60-second budget.
So instead of:
User message → API 1 → API 2 → API 3 → Reply (all counted in one 60s window)
Do:
User message → API 1 → "Proceed?" message (user clicks) → API 2 → API 3 → Reply (turn 1: 60s) (turn 2: fresh 60s)
4. Step-by-step: adding a break point
Open the flow in the builder.
Find the point between two REST API nodes where the combined time so far is getting close to 60s (or simply between every 1-2 API calls, to be safe).
Insert a Message node (or a button/quick-reply node) right after the first API call finishes and before the next one starts.
Ask the user to tap "Proceed" or similar to continue.
Connect the button click to the next REST API node.
This way, each leg of the journey (before and after the user taps) gets its own fresh 60-second window.
For further assistance or to raise feature requests related to Rest API timeout, please contact [email protected].