Error Handling

When an action fails, you decide how the automation responds: retry, skip, branch to a repair path, rewrite the alert, or escalate. APIANT exposes several orthogonal levers.

The four levers below configure retry count, 401 carve-outs, suppression windows, and alert text templates per-automation.

Levers

• Retry count — automatic retries on failure. Applied per-action or globally.
• 401 carve-out — skip retries on auth failures (they won't succeed until credentials are refreshed).
• Alert suppression — quiet windows after first failure; avoid flooding on rate-limit storms or downstream outages.
• Alert text rewriting — per-automation alert templates; replace the default platform alert with a domain-specific message.

Failure routing

Levers tune what happens at the point of failure. Routing decides where the automation goes next.

• Error subroutines — branch to a repair automation on failure. When a downstream action fails, invoke an error subroutine that emails the user, logs the failure, and retries later.
• Conditional branching on error — the "error" output field on every action can gate a conditional that routes the flow.

Pattern: retry with fallback

1. Action A calls the primary API.
2. On failure, a conditional checks error.
3. Error branch invokes Action B (a fallback: different endpoint, cache read, or a queued retry).
4. On second failure, route to an error subroutine that records the event and alerts a human.