Retries, errors & fan-out

Open a step's Advanced settings to control how it behaves when things go wrong or when there is a lot of data.

On error

A routed error looks like this:

{ "error": {
    "message": "The service rejected the request: invalid email",
    "step": "create_contact",
    "kind": "invalid",
    "retryable": false,
    "code": "...", "key": "...", "params": { },
    "origin": "upstream",
    "provenance": { "origin": "upstream", "phase": "response", "status": "422", "placement": "cloud" } } }

kind is one of connectivity, timeout, auth, permission, policy, rate_limited, invalid, not_found, conflict, unavailable, crypto, entitlement, internal, unknown, so you can treat a rate limit differently from bad data. permission means the connected system refused the action for the connection's account; policy means a platform rule refused it before anything was sent, for example a private address reached from the cloud.

origin says where the failure came from: policy (a platform rule), upstream (the connected system answered) or transport (the network failed). provenance adds the phase, the status the system answered with, its own error code and request id when it sent them, the destination a rule judged and where the step ran. The run inspector shows the same details.

Build try/catch with two edges: error does not exist (success path) and error exists (catch path). The Error step, plan limits and failures whose outcome is uncertain always stop the run.

Retry on failure

Available on adapter steps, HTTP request and Run another flow.

• Max attempts [3, including the first try; up to 100]
• Backoff (ms) [1000], Backoff multiplier [2], Max backoff (ms) [30000]. The wait before attempt n is backoff × multiplier^n-1, capped.

Retries stop immediately when the system may already have applied a change that is not safe to repeat. Replays never retry automatically.

Idempotency key

On adapter and HTTP steps, turn on Idempotency key and choose the Key header [Idempotency-Key]. The key is stable for this run and step, so a retry or resume sends the same key and a well-behaved API applies the change only once.

Process in chunks (high-volume batches)

For bulk loads on adapter and HTTP steps, set Process in chunks of (0 = off; 10 to 100,000). Each finished chunk is recorded as it lands. If the run is retried or fails mid-way, the next attempt continues from the first unfinished chunk, so delivered records are not sent again. Cancelling takes effect at the next chunk boundary, and later steps see the complete result. Chunks of 500 to 5,000 are a good start for migrations and nightly syncs.

Repeat for each record (fan-out)

Runs one instance of the step per incoming record (or per element of a list inside the first record) and collects the results.

• Continue when: All finished [default], First finished, or A share finished with Share (%) [60].
• Parallel runs: 0 or 1 runs one at a time; up to 64 at once.

Use it to call a per-customer API for many customers at once, or to take the first answer from several providers.

Compensation (rollback)

On an adapter step, set an Undo operation and optional Undo input (built from the step's own output, for example the created record's id). If a later step fails the run, the undo operations of completed steps run in reverse order, like a saga.

Timeouts

Steps have no generic time limit: slow work is allowed to finish. Time-based controls are explicit: a form's Timeout (minutes), the Wait delay, a loop's maximum iterations, the webhook proxy timeout, and the flow's Duration alert, which notifies you without stopping the run.