Understanding Retry and Error Handling

Learn how Spojit handles errors and how to configure retry behavior.

Overview

Errors are part of any integration: APIs time out, services rate-limit, credentials expire. Spojit's retry and error handling system decides when to keep trying a failing step, when to give up, and what happens to the rest of the workflow when a step fails for good.

The system has two layers. Automatic retries handle transient failures inside a single node without you having to write fallback logic. Error propagation rules then decide what happens at the workflow level once retries are exhausted - by default the workflow stops, but you can route around failures using Condition nodes and per-node failure handling options.

Automatic Retries

Connector nodes have a built-in retry mechanism configured in the node properties panel. Set max attempts (1 to 5) to tell Spojit how many tries to make before declaring the step failed. Between attempts Spojit waits with exponential backoff, which spreads load on the target system and improves the chance a transient error resolves.

Error Types

Transient errors - Timeouts, HTTP 429 rate limits, HTTP 5xx server errors, and network resets. These are retried automatically up to max attempts.
Permanent errors - HTTP 4xx client errors (other than 429), validation failures, malformed input, and authentication failures. These are not retried because retrying would not change the outcome.

Error Propagation

When a step fails after exhausting retries, the workflow stops at that step. Downstream nodes do not execute, and the overall execution is marked Failed in the logs. The failed node's error message is captured in the per-node detail view.

Per-Node Failure Handling

Send Email nodes expose a failure handling option: fail stops the workflow, continue logs the error but proceeds.
Condition nodes can route on the success or failure of an upstream step, letting you build explicit error branches.
Parallel branches fail independently. One branch failing does not cancel the others, but the workflow as a whole is marked Failed if any branch errored.

Tips

Set max attempts to 3 for most third-party APIs. It absorbs the common transient blips without delaying real failures too long.
For idempotent operations (PUTs, deletes by ID) you can safely set higher retry counts. For non-idempotent POSTs, keep retries low to avoid duplicates.
Wrap a critical step's downstream notification in a Condition that branches on success, so failures route to an alerting connector.

Common Pitfalls

Authentication failures are not retried. Fix the connection rather than waiting it out.
Exponential backoff means a node with max attempts: 5 can take a minute or more to give up. Plan timeouts accordingly.
"Continue on failure" on Send Email hides errors from the workflow status. Use it deliberately, not as a default.
Retrying a non-idempotent action (such as creating a record) can produce duplicates if the original succeeded but the response was lost.

Learn More

Retry and error handling documentation