What happens when a custom connector's API call fails or needs retrying.

Overview

The platform classifies every response automatically — you don't configure response rules in the custom connector builder. A response with a 2xx status is a success; an error status is a failure — with built-in exceptions for statuses that are usually transient:

• 401 Unauthorized — if the connection's credentials can be refreshed, the platform refreshes them and retries the call; otherwise it fails.

• 429 Too Many Requests and 408 Request Timeout — the platform retries after a wait; if retries run out, it schedules one more retry after a longer delay instead of failing outright.

This built-in handling is what lets a connector survive expiring tokens and momentary rate limits without failing the automation.

How retries work

When a response is retryable, the connector waits (a short backoff) and sends the request again, up to a limited number of attempts; if the attempts run out, the call fails (or, for rate-limit style errors, is retried once more after a longer delay). Retries are for transient problems — a momentary 429, a timeout, an expired token — so the call succeeds on a later attempt without failing the whole automation. Genuinely permanent errors (a 400 bad request, a 404) fail immediately so the automation surfaces the real problem. For an authentication's connection request there is also a Retry on Error toggle — enable it to retry when creating a connection fails.