Spojit
Error handling

Built to survive failure.

Real integrations fail: an API blips, a rate limit hits, a record is malformed. Spojit retries transient failures with backoff, respects rate limits, and routes the ones that still fail to an error branch you control, so nothing breaks silently.

Attempt 1
retry in 1s
503 · service unavailable
Attempt 2
retry in 4s
503 · service unavailable
Attempt 3
200 · succeeded
backoff
Notify the on-call channel
Write the payload to a dead-letter store
Continue the rest of the workflow
How it works

What happens when a step fails

01

A step fails

An API returns an error, times out, or hits a rate limit partway through a run.

02

Spojit retries with backoff

Transient failures are retried automatically with exponential backoff, no extra config needed.

03

It falls to an error branch

If it still fails, the run takes the error path you defined: alert, fall back, or route to a human.

Capabilities

Recovery handled for you

Automatic retries

Transient failures are retried for you, so a momentary blip never sinks a whole run.

Exponential backoff

Each retry waits a little longer, giving a struggling service room to recover instead of piling on.

Rate-limit aware

Execution respects every upstream API limit and back-pressure signal, so you do not get throttled.

Error branches

Catch a failure and take a different path: a fallback value, a cleanup step, or a notification.

Fallbacks and defaults

Supply a safe default when a step cannot complete, so the rest of the workflow keeps moving.

Alerts on failure

Get notified the moment a run fails, with the failing step and error one click away.

Use cases

Where error handling earns its keep

Survive a flaky API

Retry a temperamental endpoint automatically instead of babysitting failed runs by hand.

Handle a rate limit

Back off and retry when an API returns 429, so large batches finish without manual reruns.

Route failures to a human

Send the records that could not be processed to someone to review, not into a void.

Alert on repeated failures

Notify the right channel when something keeps failing, so issues surface before customers notice.

The difference

Automatic recovery vs hand-rolled try/catch

Resilience is built into the runtime, instead of being something you remember to wire up in every workflow.

Let the platform handle it when

  • You want transient failures retried automatically
  • You need a clear path for the ones that still fail
  • You want to be told when something breaks

Hand-rolled error handling means

  • Retry and backoff logic copied into every workflow
  • Failures that slip by unnoticed until someone complains
  • No consistent place to handle the ones that fail

Build workflows that survive failure

Start free and ship a workflow with automatic retries and an error branch, no extra plumbing. No card needed.