Skip to main content
Multi-channel fallback lets you automatically switch message delivery from a primary channel to one or more secondary channels when delivery fails, or when no delivery status is received within a configured time period. This keeps messages reaching recipients even when a channel is unavailable or a recipient can’t be reached on it. Fallback can be used with:
  • Campaigns
  • APIs

​
Channel routing

A fallback journey moves a message through up to three channels, in order: Primary Channel → First Fallback → Second Fallback For example: WhatsApp → RCS → SMS.
A maximum of three channels can participate in a single fallback journey.

​
When does fallback trigger?

Fallback is triggered under either of the following conditions.

​
Scenario 1: Failed DLR received

A failed delivery status (DLR) is received from the primary channel, and the system immediately triggers the configured fallback channel.
Example: WhatsApp = Failed. The system immediately triggers the configured fallback channel.

​
Scenario 2: Wait time exceeded

No Delivered or Failed DLR is received within the configured wait time.
Example: Wait Time = 300 seconds. If the message is not delivered within 300 seconds, fallback is triggered automatically.

​
Wait time

Wait time defines how long the platform should wait for a delivery status before initiating fallback.
Example — Primary Channel = WhatsApp, Wait Time = 300 seconds. The system waits for a Delivered or Failed DLR; if neither is received within 300 seconds, the next fallback channel is triggered.
Wait time is defined at two points in the journey:
  • Primary → First Fallback: wait time is defined during campaign creation or in the API request.
  • First Fallback → Second Fallback: wait time is defined at the time of fallback configuration creation.

​
TTL (Time to Live)

TTL defines the maximum duration operators should attempt message delivery before marking the message as failed. In a fallback journey, TTL never outlasts the wait time.
  • Campaigns: TTL is automatically set to 95% of the wait time.
  • API and plugin sends: if the TTL you pass is longer than the wait time, the wait time overrides it. The primary attempt ends when fallback fires, which cuts down duplicate delivery on both channels. A TTL at or below the wait time is used as sent.
How TTL reaches the operator depends on the channel:
  • For SMS, TTL is submitted to operators during message submission.
  • For RCS, TTL is submitted to operators during message submission.
  • For WhatsApp, TTL must be configured at the WhatsApp template level.
TTL configuration helps avoid duplicate delivery across channels. For SMS/RCS this is predefined as supported by operators; for WhatsApp, you are strongly recommended to add TTL at the time of template creation to avoid duplicate delivery.

​
Use cases

  • Reach recipients without WhatsApp or RCS: fall back to SMS when a rich channel fails so the message still lands.
  • Recover from channel-specific failures: if a WhatsApp template message fails (e.g., recipient hasn’t opted in), automatically retry on RCS or SMS.
  • Avoid silent delivery gaps: the wait-time trigger catches messages stuck with no DLR at all, not just explicit failures.

​
Next steps