HTTP and Code: Retry With Backoff and Fallback Template

A scheduled Spojit workflow that calls a flaky REST API with the http connector, retries with backoff when it fails, and falls back to a secondary endpoint so a single bad response never breaks your automation.

What It Builds

A Schedule trigger fires on a cron you choose, then a Connector node on the http connector calls your primary REST API with http-get. When the call fails or times out, a Connector node on the code connector runs execute-javascript to wait, back off, and retry a few times, and if the primary still does not answer it calls a secondary endpoint instead. A Condition node routes the final outcome so a healthy response continues downstream and a total failure raises an alert with a Send Email node.

The Prompt

Paste this into Miraxa, the intelligent layer across your automation, and it builds the workflow, connecting the tools for you:

Build a workflow on a Schedule trigger that runs every 5 minutes. Use the http connector to GET https://api.example.com/v1/status from my primary API. If the request fails or returns an error status, use the code connector with JavaScript to retry up to 3 times with exponential backoff (1s, 2s, 4s), and if it still fails, call my secondary endpoint https://backup.example.com/v1/status instead. Add a Condition node that checks whether a healthy response was returned: on the true branch continue, and on the false branch send me an email saying the primary and fallback both failed.

Connectors Used

  • Schedule trigger - fires the workflow on a 5-field cron and timezone you set (for example */5 * * * *).
  • http - calls your primary and secondary REST APIs with http-get (swap to http-post or http-request for other methods).
  • code - runs execute-javascript to handle the wait, backoff, and retry loop and to call the fallback endpoint.
  • Send Email node - alerts you from Spojit's built-in mail service when both the primary and fallback fail.

Customize It

Change the two URLs to your own primary and backup endpoints, and edit the cron in the prompt to match how often you need the check (for example hourly with 0 * * * *). Tune the retry count and the backoff delays (1s, 2s, 4s) to fit your API's rate limits, and adjust the email recipient and message. If your API needs a key, tell Miraxa to pass it in the Authorization header, and add the value as an API key connection rather than hard-coding it in the prompt.

Tips

  • Keep the http nodes in Direct mode: the calls are deterministic, so you map inputs yourself and spend no AI credits.
  • Use exponential backoff (each wait roughly double the last) so a struggling API gets room to recover instead of being hammered by rapid-fire retries.
  • Reference the primary result downstream with a variable like {{ primary.body }} so the same field name works whether the response came from the primary or the fallback path.

Common Pitfalls

  • Watch the schedule interval against your retry timing: if a single run can wait several seconds across retries, do not set a cron that fires faster than a run can finish.
  • Treat a non-2xx status as a failure explicitly in your execute-javascript logic. A response that arrives with an error status is still a "successful" HTTP call, so check the status code before deciding to retry.
  • The Send Email node only delivers to addresses on your org allowlist. Add your alert recipient under Settings > General > Email recipients first, or the failure alert will not send.

Related Articles

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.