Configure Retry-on-Fail with Sensible Defaults for External API Calls

Any node that calls an external API should have Retry on Fail enabled. Network glitches, transient 502 errors, and momentary rate limits are common, and a simple retry policy recovers from most transient failures automatically without manual intervention. The three settings to configure are Retry on Fail, Max Retries, and Wait Between Retries, tuned to how quickly the API recovers.

Real-world example: A workflow sends order confirmations via SendGrid. Once a week, SendGrid returns a transient 500 error. Without retries, that customer never gets their confirmation. With retries, the second attempt succeeds 2 seconds later.

How do you configure Retry on Fail?

# Node Settings panel (click the gear icon on any node)

# Recommended defaults for any node calling an external API

Settings:
  Retry On Fail: true
  Max Retries: 3
  Wait Between Retries: 1000   # milliseconds (1 second)

# These settings mean:

# - If the node fails, wait 1 second and try again

# - Up to 3 additional attempts (4 total including the original)

# - If all retries fail, the error propagates to the error workflow

How should you tune retries for each type of API?

Tune the settings based on the API:

Fast APIs (SendGrid, Slack, Twilio):
  Max Retries: 3
  Wait Between Retries: 1000
  Rationale: These APIs recover quickly from transient errors

Slow APIs (LLMs, data processing):
  Max Retries: 2
  Wait Between Retries: 5000
  Rationale: Longer operations need more time, but fewer retries
             to avoid long execution times

Rate-limited APIs (Twitter, LinkedIn):
  Max Retries: 5
  Wait Between Retries: 10000
  Rationale: Rate limits reset after a window; longer waits help

Idempotent-safe APIs only:
  Retries are only safe if the API operation is idempotent.
  GET requests: Always safe to retry
  POST requests: Only safe if the API handles duplicates
                 (check for idempotency key support)
  DELETE requests: Usually safe (deleting twice = same result)

Warning: Do not retry non-idempotent operations blindly

If a POST request to a payment API times out, retrying might charge the customer twice. For non-idempotent operations, implement idempotency checking (see Webhook Tips, Tip 6) before enabling retries.

These three settings -- Retry on Fail, Max Retries, Wait Between Retries -- should be your default configuration on every HTTP Request node, every API integration node, and every database node in production workflows.

Related: Use "Pin Data" to Freeze Node Output · Break Large Workflows into Sub-Workflows