Failover message

Failover switches automatically to a backup channel when the send on the primary channel fails.

The key is the messageFlow field in the request body. messageFlow holds message objects in order as an Array, and if the message earlier in the order fails, the next message in the order is sent automatically as the failover.

Different channels use the same /api/omni path because the design distinguishes channels inside the messageFlow specification rather than by URL.
In other words, Bizgo's unified message model (omni) lets you control the message combination and the priority from the request body.

{
  "destinations": [{ "to": "01000000000" }],
  "messageFlow": [
    { "alimtalk": { "msgType": "AT", "text": "주문 안내 메시지입니다." } },
    { "sms": { "from": "01000000000", "text": "알림톡 대체 문자입니다." } }
  ]
}

{
  "destinations": [{ "to": "01000000000" }],
  "messageFlow": [
    { "alimtalk": { "msgType": "AT", "text": "안내 메시지입니다." } },
    { "rcs": { "serviceType": "RCS", "msgType": "RS", "content": { "description": "RCS 대체 메시지입니다." } } },
    { "mms": { "from": "01000000000", "subject": "대체 안내", "text": "RCS 실패 시 LMS 대체 발송입니다." } }
  ]
}

How it behaves

[Request starts: /api/omni]
        |
        v
[messageFlow[0] 1st priority send]
   | success --------------> [send complete]
   | failure
   v
[messageFlow[1] 2nd priority send]
   | success --------------> [send complete]
   | failure
   v
[messageFlow[2] 3rd priority send]
   | success --------------> [send complete]
   | failure
   v
[final failure handling]

Example strategies

1. Switch to SMS when Alimtalk fails
2. Retry with RCS after Alimtalk fails, then switch to LMS if that fails

Design recommendations

• Define the switching conditions (failure code, timeout) clearly.
• Line up the template length and the substitution variables for each channel in advance.
• Apply idempotent handling on the same message key to prevent duplicate sends.
• Review your messageFlow design criteria together with the SMS/LMS/MMS specification.