Fallback chain
Qué es Fallback chain?
Esta entrada está disponible actualmente solo en inglés.
A fallback chain is the ordered list of channels a message escalates through when a hop cannot reach the recipient or delivery fails — for example, RCS first, SMS next, WhatsApp last. The escalation engine advances to the next channel only when a terminal failed, undelivered, or rejected receipt lands inside the fallback window; every hop of one chain shares one message_group_id and re-enters the send pipeline, so consent and opt-out gates re-apply on each hop.
More detail
The chain resolves from up to three sources in a fixed precedence — a raw fallback channel list on the send metadata, then the typed cascade field on the send body, then the org-level default cascade policy — and sources never merge, so a caller's own chain is never silently over-filed by the org default. A typed field with a single disabled flag opts one send out of the org policy.
Each advance dispatches the next channel as a brand-new send: the remaining tail of the chain and the shared group id carry forward, the hop records which message it fell back from and the terminal status that triggered it, and a hop-bounding idempotency stamp guarantees at most one dispatch per message regardless of duplicate carrier receipts. Every hop bills on its own channel, with no extra fallback fee class.
Fallback chains compose alongside the org-level capability chain rather than replacing it: the capability chain handles recipients a channel cannot reach at all (a recipient with no RCS support, for example), while the fallback chain handles hops the channel could reach that still terminate in a failed or undelivered receipt. The notify composer's waterfall mode composes the same per-recipient chain in one call and returns a single composed receipt.
Preguntas frecuentes
- How does a fallback chain decide when to advance to the next channel?
- Only on a terminal receipt — a failed, undelivered, or rejected status delivered by the carrier inside the fallback window. An in-flight status never advances the chain, and once the window closes the terminal receipt no longer escalates: the chain stops instead of sending stale messages hours later.
- Does every hop in a fallback chain retry the recipient's contact details?
- No. Each hop re-enters the canonical send pipeline on its own channel, so sender resolution, recipient opt-outs, and quiet-hours consent gates re-apply per hop — an SMS opt-out blocks the SMS hop even if the recipient accepted the RCS primary — but the chain never changes who the message targets.
- How do I read a finished fallback chain back as one message?
- Every hop carries the same message_group_id, so the cascade groups endpoint returns each leg oldest-first with the fallback reason per hop. In the dashboard the Messages view groups those legs primary-first on one envelope, so operators see one logical message rather than several disconnected sends.
See also
Build it on Orbit
Voice, messaging, email, video, and AI agents on one platform and one pay-as-you-go bill. Start free — no credit card required.