Provider retry policies

Provider retry policies handle short-lived failures before Delphi moves to a configured fallback provider or call-level error action. Policies are role-specific: STT, TTS, Realtime, and Bot/LLM can use different timeout and retry values.

Where to configure retries

Scope	Path	Use it for
Platform	/admin-settings → Platform Settings → Resilience defaults	The baseline for all teams.
Team	/settings → Team → Resilience defaults, then enable the team override	A team that needs a different policy from the platform baseline.
Flow	Default provider or a voice agent's Provider override → Timeouts & retries	A specific provider in a flow that must replace the inherited role policy.

The closest configured policy wins. See Inheritance and overrides before setting only one field in a team or flow override.

Built-in defaults

When no platform, team, or flow value replaces them, Delphi uses these runtime defaults:

Provider role	Request timeout	Retries after the initial attempt	Retry categories
STT	10,000 ms	0	timeout, network
TTS	5,000 ms	1	timeout, network, rate_limit, server_error
Realtime	15,000 ms	1	timeout, network, rate_limit, server_error
Bot/LLM	15,000 ms	1	timeout, network, rate_limit, server_error

All roles also use:

• Initial retry delay: 500 ms.
• Backoff factor: 2.
• Retry HTTP status codes: 408, 429, 500, 502, 503, 504.

STT does not retry by default

The built-in STT retry count is 0, so its status-code list takes effect only after you raise the retry count. This avoids adding recognition latency unless you opt in.

Retry HTTP status codes

Enter a comma-separated allow-list in Retry HTTP status codes. Codes must be whole numbers from 100 to 599, with at most 32 entries. The policy applies to both normal HTTP responses and HTTP responses returned while opening a WebSocket connection.

The decision rules are:

1. If the failure includes an HTTP status, Delphi retries only when that exact code is in the allow-list.
2. If the failure has no HTTP status, Delphi uses its retry category, such as timeout or network.
3. An excluded status does not fall through to its category. For example, removing 429 prevents a retry even though rate_limit is an enabled category.

Keep the default list for common transient failures. Avoid adding authentication, permission, or invalid-request 4xx responses unless the upstream service explicitly documents them as transient; repeating the same request normally cannot fix those errors.

Clearing the field removes the explicit list. If that leaves the complete role or provider block empty, inheritance resumes; if other fields remain in the block, the built-in list applies. To deliberately disable every status-based retry, use the source view and set an explicit empty list:

{
  "resilience": {
    "retryCount": 1,
    "retryStatusCodes": []
  }
}

An explicit empty list is a real override. It does not restore the default codes.

Retry timing and fallback

Retry count means additional attempts with the same provider, after the initial attempt. For example, a retry count of 2 permits up to three total attempts.

The delay grows exponentially. With a 500 ms initial delay and a backoff factor of 2, Delphi waits 500 ms before the first retry and 1,000 ms before the second. Individual delays are capped at 60 seconds.

When the error is not retryable or the retry count is exhausted, Delphi proceeds to the configured provider fallback or call-level failure handling. Ending or cancelling a call aborts an in-flight attempt and any pending retry delay, so retries do not continue after the call has stopped.

Inheritance and overrides

Provider policy selection resolves from broadest to most specific:

1. Platform role default.
2. Team role override, when configured.
3. The provider's Timeouts & retries block in the flow.

If no block is configured, Delphi uses the built-in runtime policy. After a team or flow block wins, fields that are unset in that block use built-in runtime values rather than values from the replaced block.

Role and provider blocks are replaced as units, not merged field by field:

• A team-level TTS block replaces the complete platform TTS block. Other roles can still inherit their platform blocks.
• Any concrete value in a flow provider's retry block makes that complete block the provider override. It no longer inherits the team or platform role block.
• Primary and fallback STT/TTS providers inherit the effective role default when they do not have their own concrete retry block.
• Clearing every field in a flow provider's retry block restores inheritance.

Include the values you want to preserve

If the platform TTS policy defines a custom status-code list and a flow overrides only the TTS timeout, that provider no longer inherits the platform list. Enter the desired status codes in the flow override too, or clear the complete flow override.

Troubleshooting

• No retry occurs: confirm Retry count is greater than 0 and the returned status is in Retry HTTP status codes.
• A 429 or 5xx fails immediately: check the effective status-code allow-list. Retry categories cannot re-enable an excluded HTTP status.
• A platform or team value appears ignored: inspect the provider's Timeouts & retries section for any concrete field, which makes it a complete provider override.
• Retries are too slow for a live call: reduce the timeout, retry count, or initial delay; then test the complete fallback path before publishing.

See also

• Providers overview
• Flow Designer inspectors
• Platform resilience defaults
• Team resilience defaults
• Speech playback and hangup