The Error Handler node wraps a single step in a safety net. It attempts to run that step, optionally retries it if it fails, and then routes your flow down a Success path or an Error path depending on the outcome — so one failed API call or integration doesn't crash your entire automation.
Use an Error Handler whenever a step is calling something that could realistically fail or be temporarily unavailable, such as:
An HTTP request to a third-party API that might time out
An integration step (Mailchimp, Notion, Gorgias, etc.) that could hit a rate limit
Any step you want to fall back gracefully from — for example, sending a Slack alert instead of letting the whole flow stop
This node protects exactly one other node — the one it wraps — rather than an entire branch:
Place the Error Handler node before the node you want to protect.
Connect the node you want to protect into this node's input.
Draw a Success edge from this node to your happy path.
Draw an Error edge from this node to your recovery path (e.g. a Slack alert or fallback step).
Field Required Description Step name Yes (defaults to tryResult) A name for this step's output, used to reference it later in your flow. Retry on failure No (defaults to 0) How many extra attempts to make if the step fails, from 0 to 3. Retry delay strategy Only shown if retries > 0 No delay retries immediately; Linear waits 1s, 2s, 3s… between attempts; Exponential waits 1s, 2s, 4s… Base delay Only shown for Linear/Exponential The starting delay in milliseconds (500–30,000) that the strategy scales from.
The result is stored under the Step name you chose, with these fields available:
Reference Returns {{tryResult.status}} "success" or "error" {{tryResult.error.message}} The error message, if the step failed {{tryResult.attempts}} How many attempts were made (see note below)
(Replace tryResult with whatever Step name you chose. The error object also includes error.name and error.stack if you need more detail for debugging.)
Most of the time you won't need to reference the output directly — just connect your next steps to the Success or Error side of the node, and Syncaut handles the routing automatically.
Whichever path doesn't run (Success or Error) has its connected steps automatically skipped for that run.
Some errors are marked as non-retriable internally (for example, validation errors like a missing required field). These stop immediately and go straight to the Error path regardless of your retry setting — retries are best suited for transient issues like timeouts or rate limits, not configuration mistakes.
Heads up: the attempts value in the output currently doesn't always reflect the real number of tries — on success it always shows 1 even if it succeeded after a retry, and on failure it shows the maximum configured attempts even if it stopped earlier due to a non-retriable error. Treat status and error.message as the reliable signals for now rather than relying on attempts for exact retry counts.
Navigate