> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Cross-channel fallback: the ordered chain that retries a failed send on the next channel > How Orbit advances an outbound message through an org-configured channel chain (RCS → SMS, Viber → WhatsApp → SMS, ...) on capability failures, provider exhaustion, or unreachable recipients — with a TCPA re-check and billing behavior at every hop. # Cross-channel fallback Sending through fallback is a two-step move — **resolve, then route.** The resolve step fixes which fallback plane owns the send, in a fixed precedence. The **org-level chain** (this page) answers *can this channel carry this recipient at all*, and it resolves first: a capability failure short-circuits before any delivery receipt exists, so the **per-request DLR fallback** ([Fallback on terminal DLR](/concepts/multi-channel-dlr-fallback)) — whose trigger, a terminal DLR from the carrier, can only arise after the send was accepted — never fires on that attempt. The **campaign `channels[]` ladder** layers per-campaign engagement triggers and timed windows on top of both. The route step is this page's model: an **org-level, ordered chain of channels** the router advances through when the current channel cannot deliver. A typical chain is `RCS → SMS` or `Viber → WhatsApp → SMS`: configure it once on the organization, and every send on the primary channel transparently retries the next channel when the attempt fails. The rest of the page covers what triggers an advance, what the chain does and doesn't cover, how it differs from the campaign-level ladder, and what happens at the billing and compliance layers on each hop. The channel-specific details (which triggers apply, provider tiers, request envelopes) live on the [RCS](/channels/rcs) and [Viber](/channels/viber) pages; this page covers the model they both follow. ## What it is You configure a fallback chain once, on the organization. Every channel entry after the first is tried in order when the previous one fails. The chain lives under `settings.cross_channel_fallback` and takes effect on the next send — no redeploy, and no change to your send-path code. Because the chain is org-level rather than per-request, it applies uniformly to every outbound send path in Orbit: direct API sends, campaign blasts and journeys, and inbox replies all inherit the same fallback behavior without the caller setting anything. ## Configuring the chain From the dashboard: 1. Open **Settings → Channels → Cross-Channel Fallback**. 2. Add a rule with the **Primary** channel and one or more **Fallback** channels (e.g. `RCS → SMS`, or `RCS → WhatsApp → SMS`). 3. Save. The change takes effect on the next send. The same configuration is readable and writable over the API at `GET` / `PUT /api/v1/settings/channels-fallback` (see the [settings reference](/api-reference/endpoints/settings)), so you can manage it alongside the rest of your channel settings in automation. ## What triggers an advance The router advances to the next channel in the chain on a **channel-specific reachability failure** — not on any arbitrary error. Concretely, the triggers are: * **Capability check fails.** The recipient's device or registration doesn't support the channel (e.g. the RCS capability cache or a live capability probe returns `not_capable`; a Viber send finds the number not registered with Viber). The attempt short-circuits and the router advances immediately. * **Provider exhaustion.** Every registered provider for the channel returned a non-retryable error within the configured retry budget. * **Recipient unreachable on the channel.** The channel's own reachability gate rejects the recipient (for example, a recipient who has not opted in to RCS in their messaging app). Whatever the trigger, advancing the chain produces a **new message attempt on the next channel** — it is not a silent rewrite of the original attempt, and it surfaces in delivery reporting as its own send. ## What it explicitly does not do **There is no per-request fallback flag.** Send endpoints like `POST /messages/rcs` and `POST /messages/viber` do not accept a `fallback` body field — passing one is ignored. Fallback behavior is entirely driven by the org-level configuration, so it stays consistent across every send path instead of depending on callers remembering to opt in. **The trigger set is closed.** A fallback advance only happens on the reachability failures listed above. A channel that the recipient genuinely uses but that rejects the content (for example, a moderation or template rejection) is not a fallback trigger by itself. ## Compliance: TCPA re-check at every hop Reaching SMS as a fallback hop does not inherit the opt-in the recipient gave to the primary channel. When the chain advances to SMS, Orbit re-runs the SMS opt-out and DNC check against the recipient before delivering. If the recipient has opted out of SMS — even though they accepted RCS or Viber — the message is suppressed rather than delivered over SMS. This re-check runs on every hop into SMS, regardless of which channel the chain started on. ## Billing: the fallback hop bills on its own channel A fallback hop is priced and charged on the channel it lands on. When the chain falls through to SMS, the SMS send flows through the standard SMS billing path and is charged accordingly — the [Messaging API reference](/api-reference/endpoints/messaging) covers the full envelope. Expect fallback usage to show up as ordinary SMS spend; there is no separate fallback charge class. ## Campaign-level variant: the `channels[]` ladder Campaigns have a second, more granular fallback shape. On an omnichannel campaign the `channels` array is an **ordered per-campaign ladder** (depth-capped, no duplicate channels): each non-final entry carries its own `fallback_on` trigger (`failed`, `no_delivery`, or `no_engagement`) and a `fallback_after_seconds` window, and the last entry is terminal. When a ladder is present, the campaign's top-level `channel` must equal the ladder's first entry. The two mechanisms layer on top of each other: * The **org-level chain** handles channel-specific reachability failures on every send path, with no campaign involvement. * The **campaign ladder** adds per-campaign control — including engagement-based triggers (`no_engagement`) and timed windows (`fallback_after_seconds`) — that the org-level chain's capacity/provider triggers alone can't express. The campaign dry-run surfaces the effective fallback shape as `channel_waterfall` (primary channel plus the configured cross-channel fallback chain with per-step provider state), so you can verify exactly what chain the launch will walk before it goes out — see the [campaign end-to-end guide](/guides/campaign-end-to-end). ## Where it does not apply Cross-channel fallback applies to outbound messaging only. It does not apply to inbound routing (covered by [inbound message routing](/concepts/inbound-message-routing)), to voice calls, or to email sends — none of which participate in the messaging chain.