Fallback

Retry across registries when an upstream fails — configure the ordered chain and triggers on the consumer Routing tab.

Fallback turns a single upstream failure into a retry on the next registry instead of an error to the client. Configure it per consumer on the Routing tab when Strategy is Fallback (or when fallback is enabled alongside your routing setup).

Configure fallback in the UI

1. Open Consumers → select a consumer → Routing.
2. Set Strategy to Fallback (under Direct).
3. Build the chain — the ordered list of registries to try.
4. Choose triggers (which failures start a retry) and optional budget (max attempts / total latency).
5. Save.

Triggers

A retry only happens when the failure matches a configured trigger:

Trigger	Fires on
HTTP 5xx	Upstream 5xx responses.
HTTP 429	Upstream rate-limit responses.
Timeout	Upstream timeouts.
Provider error	Provider-reported errors.
Plugin rejection	A policy rejected the request.

Budget

The budget caps how hard TrustGate tries:

• Max attempts — total forward attempts (including the first).
• Max total latency — wall-clock ceiling across all attempts.

When either limit is reached, the last error is returned to the client.

The chain

The chain is the ordered list of registries to try. On each failure TrustGate moves to the next entry and does not re-pick an already-failed registry within the same request.

Use fallback to span providers (for example OpenAI → Azure OpenAI → Bedrock) for resilience, or to degrade from a premium model to a cheaper one under load.

See also Load balancing, Smart routing, and Model resolution.