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. A simple retry policy recovers from most transient failures automatically without any manual intervention.

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.

# 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

```text
Tune the settings based on the API:

```yaml
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)
```text
> **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](../testing-and-debugging/01-use-pin-data-to-freeze-node-output.md) | [Break Large Workflows into Sub-Workflows](../workflow-architecture/01-break-large-workflows-into-sub-workflows.md)