Reliability

Handle errors, retries, and third-party rate limits so your integrations stay resilient in production.

Real integrations fail in expected ways: a third-party API returns an error, a request is rate limited, or a workflow runs twice. Build for those cases so a single failure doesn’t break a customer’s integration. Use error handling inside workflows, retries and replays from the logs, and idempotency to make repeats safe.

Handle errors in a workflow

Wrap steps that can fail in a Try-Catch node so the workflow can react to an error instead of stopping. The catch branch lets you log the failure, send a notification, or fall back to an alternative path, while the rest of the run continues.

Retry and replay failed runs

When a run errors, you don’t have to rebuild it. From the Executions tab in Logs:

• Retry re-runs a single errored node.
• Replay re-runs the whole workflow.

Replay is limited to a single attempt per run.

Make repeats safe with idempotency

Retries, replays, and duplicate triggers can run the same workflow more than once. Without protection, that repeats side effects, such as creating the same record twice. Use idempotency so a repeated execution is recognized and doesn’t duplicate work.

Rate limiting

Third-party apps enforce their own API rate limits, and exceeding them returns errors that can fail a workflow. Design workflows that call high-volume APIs to stay within those limits and to handle rate-limit responses gracefully.

See also

• Logs: find and replay failed runs.
• Workflow testing: catch failures before they reach production.
• Idempotency: prevent duplicate side effects.