Skip to main content

Regional OTT channel model

KakaoTalk, Zalo, WeChat, and LINE are the four regional OTT channels in Orbit: the messaging apps that own their home markets the way SMS owns the rest of the world. Each is a first-class channel with its own send route, credentials, and delivery receipts, documented on its own channel page (KakaoTalk, Zalo, WeChat, LINE). What those pages do not cover is the model the four share: delivery on these channels is gated by a relationship between the recipient and your sender profile, not by the recipient’s phone number. This page owns that model, the follower gate, and its routing consequences for anyone building fallback chains into these markets.

1. Two kinds of reachability

Every channel in Orbit resolves one question before a send commits: can this recipient be reached on this channel? The channels answer it in two different ways:
  • Phone-number reachability. SMS, Viber, and WhatsApp address the recipient by MSISDN. If the number is valid, in coverage, and (for WhatsApp and Viber) on the app’s network, the send can proceed. The recipient has never heard of your brand and the message still arrives, because the address is the number.
  • Follower / friend reachability. KakaoTalk, Zalo, WeChat, and LINE address the recipient through a relationship the recipient created with your sender profile: a channel added as a friend, an Official Account followed, a bot friend-added. The phone number is still necessary (these apps bind accounts to numbers) but not sufficient. A Korean number is reachable by SMS whether or not its owner ever opened KakaoTalk; a KakaoTalk Friendtalk message to the same number lands only if that person added your channel.
The split matters because every reachability check you can run against a phone number (the Number lookup and reachability model, carrier lookups, the coverage dimensions in the Channel capability coverage matrix) measures the first kind. The follower gate is the second kind, and no phone-number probe observes it.

2. The relationship each channel requires

  • KakaoTalk splits the gate by message type. Alimtalk (알림톡) is the notification class: pre-approved templates that reach any Korean phone number with no follow required, the one exception among the four. Friendtalk (친구톡) is the marketing class: free-form text and image, delivered only to users who added your channel as a friend. See KakaoTalk message types.
  • Zalo delivers ZNS templates against the customer’s phone number through your Official Account. The number must belong to a Zalo account that can receive notifications from your OA. A customer who never installed Zalo, or whose relationship with your OA does not permit ZNS, is unreachable on this channel however valid the number is.
  • WeChat is the strictest form of the gate: the send does not take a phone number at all. The to field is the follower’s openid, an Official-Account-scoped id that only exists once the user followed your OA. No follow, no openid, no address to send to.
  • LINE follows the same shape with a friend-add in place of a follow: pushes target a LINE user ID that your bot only learns when the user adds it as a friend.

3. Why a chain hop fails on a reachable number

A cross-channel fallback chain is configured once per organization and evaluated per recipient at send time. That split is where the rejected hop comes from:
  • At configuration time, the router validates what is statically knowable about each entry: the channel is connected for your organization, the entry respects the market and family boundaries described in Geography boundaries, and a template-only channel has an approved template attached. An entry that fails any of these is rejected when you save the chain, not discovered mid-send.
  • At send time, the router re-validates eligibility against the actual recipient, and the follower gate is the one precondition that only exists at this moment, per recipient. The phone-number reachability check that made the recipient look eligible for the hop says nothing about whether they follow your Official Account or added your KakaoTalk channel. The hop then fails in one of two visible ways: the provider rejects the send (WeChat errcode 40003, unknown openid, meaning not a follower; a KakaoTalk gateway rejection for an unfollowed Friendtalk recipient), or the recipient has no address on that channel and the hop cannot fire.
Either way the number was reachable and the hop still died. That is not a router defect; it is the follower gate doing its job. The chain’s contract is that a failed hop advances to the next entry, so the correct construction is to treat these channels as conditional primaries, chosen when you know the relationship exists, and keep SMS as the hop that catches everyone else. The Channel capability coverage matrix states the same rule from the eligibility side.

4. Template-only transactional posture

Three of the four channels constrain what you may send, not just to whom:
  • Zalo (ZNS) is template-only. Every send references an approved template id with named variables; there is no free-form body at all. A send without an approved template_name is rejected with VALIDATION_ERROR before it leaves Orbit.
  • WeChat OA is template-only for outbound pushes: an approved template id plus {{key.DATA}} variables, with at most an H5 deep link attached.
  • KakaoTalk Alimtalk is template-only in the same sense: approved template code, filled #{var} variables, no free-form body. Friendtalk carries free-form text, but only to channel friends.
LINE is the exception on both axes. Pushes are free-form (plain text plus image, video, audio, location, sticker, and Flex Message payloads) and need no per-message template approval. That makes LINE the natural rich primary inside Japan, Taiwan, and Thailand, the role RCS or WhatsApp plays elsewhere; the only gate is the friend-add. The routing consequence: a chain that descends into Zalo, WeChat, or Alimtalk re-enters that market’s template gate. The payload that rode the previous hop does not survive unless an approved template exists for it, so a chain entry on these channels needs an approved template per market, prepared before the chain is saved.

5. Geography boundaries

Each app is bounded to its home market: Treat each as an Orbit-side boundary for the fallback chain: a hop into one of these channels only reaches a recipient inside that app’s home market who additionally passes the follower gate from section 2. A Vietnamese number in a KakaoTalk hop is never eligible; a Korean number in a LINE hop likewise. The home-market-only rule also means these channels never substitute for SMS reach outside their market: a chain for a global audience keeps SMS as its floor, with the regional app layered on top for its market only.

6. Routing implications for cost-aware chains

Least-cost routing and cost-aware re-sequencing rank channels by cost class on the assumption that a cheaper eligible channel tried first saves the pricier hop behind it. The regional OTT channels complicate that assumption in two ways:
  • They are send-capable but chain-ineligible outside their family and home market. Inside the home market, and for recipients who pass the follower gate, they are often the cheapest and highest-engagement hop you own. Outside it, they are not a routing option at all: re-sequencing a chain to try Zalo before SMS for a non-Vietnamese audience does not save money, it adds a hop that can never deliver.
  • Eligibility is per relationship, not per number. Even inside the home market, the cost ordering only holds for the audience segment that follows you. The honest cost model splits the audience: followers get the OTT hop first (cheaper and richer than SMS), non-followers go straight to SMS, or to Alimtalk where the notification posture applies. Chain construction that ignores the split pays for failed hops without saving any.
Sequence these channels by known relationship and known market, never by sticker price alone. The Route preview model shows the hop a send will take before it commits; use it to confirm the regional hop actually fires for a sample of your audience before you promote it ahead of SMS.

7. Worked example: a Korean recipient on an SMS-only footprint

An organization encodes the chain kakao → sms for its Korean traffic and sends an order confirmation to a valid Korean mobile number whose owner never added the organization’s KakaoTalk channel:
  1. Hop 1, KakaoTalk as Friendtalk. The number is valid and in-market, but the recipient never added the channel. The follower gate fails and the hop is rejected. If the send were Alimtalk, this hop would succeed: the notification posture needs no follow, only an approved template.
  2. Hop 2, SMS. The chain advances past the failed hop and the message delivers to the number. The recipient is reached; the KakaoTalk hop cost nothing but a routing decision.
Send the same chain to a recipient who did add the channel: hop 1 delivers on KakaoTalk (cheaper per message, native to the recipient’s default app) and SMS never fires. The chain is identical; the outcome differs entirely on the recipient-side relationship. That asymmetry is the whole model: the chain encodes which channels to try, and the recipient’s relationships decide which try succeeds. Encode the chain with SMS as the floor, place the regional app ahead of it only for audiences whose follow or friend-add you have recorded, and reserve Alimtalk, ZNS, and WeChat OA templates for the transactional traffic whose template approvals are already in place.

Where the other models plug in