Skip to main content

​
Channel capability coverage matrix

Every channel page under Channels documents one channel’s full surface. That granularity answers “how do I use channel X,” but the question a routing decision actually asks is across channels: can RCS carry this payload, is the recipient reachable on it in this market, and if not, which channel next? This page owns the unifying model — the capability taxonomy, the coverage dimensions that gate a channel per recipient, which rounds of channels are eligible for the org-level fallback chain, and a one-row-per-channel index into the individual channel pages. It deliberately does not re-teach each channel’s send shapes; it indexes them.

​
1. Capability taxonomy

A capability in Orbit is a named, machine-checkable message feature — not a vague “this channel is rich.” Every channel is assessed against the same taxonomy, so comparing them is apples-to-apples:
  • Send — outbound (MT) delivery: text, or text plus structured payloads.
  • Receive — inbound (MO) delivery into the inbox and webhooks.
  • Templates — a pre-registered, provider-approved structured shape (WhatsApp templates, RCS rich cards/carousels, Messenger generic templates, email block-builder templates).
  • Media — attachments beyond plain text: images, video, audio, documents.
  • Delivery receipts (DLRs) — a terminal delivery verdict from the carrier or provider, distinguishing delivered from the three failure classes described in Message status lifecycle.
  • Read receipts — a recipient-opened signal beyond delivery: RCS and Viber seen, WhatsApp/Meta read, email open-tracking.
These are the columns in the matrix below. A channel’s mapping to them is fixed by its upstream provider, not by Orbit — the matrix is a description of provider contracts, not a product toggle.

​
2. Coverage dimensions

Having a capability is necessary but not sufficient. Whether a channel can carry a specific recipient is gated by three coverage dimensions, each checked before the send commits:
  • Geography. Channel reach varies by recipient market. SMS reaches effectively every MSISDN worldwide; RCS depends on per-carrier RBM rollout in the recipient’s country; Viber availability is market-bounded by Rakuten’s allow-list; WhatsApp and Messenger are near-global but live behind Meta’s per-market business policies. The recipient’s number and country are evaluated the same way the Number Lookup and reachability model evaluates them.
  • Feature set. The exact capability needed: media stops the chain at SMS unless MMS carries it; interactive buttons belong to WhatsApp, RCS, and Messenger templates; voicemail-style one-way blasts belong on voice.
  • Cost class. Channels cluster into per-message-charged carriers (SMS, RCS, Viber), Meta conversation-priced channels (WhatsApp, Messenger), and flat/unmetered lanes (email, push). A routing policy like Least-cost routing treats the class, not the sticker price, as the comparable axis.
Note — pricing lives elsewhere. Per-channel rate resolution, the pricing ladder, and route preview are owned by Least-cost routing and the Route preview model. This matrix ranks channels by cost class only — it never quotes rates.

​
3. Fallback eligibility

The org-level chain (Cross-channel fallback) advances a failed send to the next channel — but only across deployments where the next hop can plausibly reach the same recipient. The candidates, in the order a chain normally descends:
  1. Rich messaging carriers — RCS, WhatsApp, Viber. Each is eligible as a primary and as a fallback hop (the canonical RCS → SMS chain; Viber → WhatsApp → SMS).
  2. SMS (MMS where media applies) — the floor of every messaging chain: the one channel reachable on virtually every handset.
  3. Email — eligible as a terminal hop for notification-class traffic where content survivability matters more than real-time delivery; not eligible mid-chain for interactive payloads, since email does not carry them.
  4. Voice / fax — never in the message fallback chain. Their delivery surface (a call, a document) is not interchangeable with a message, so the router never advances a message send onto them; they are configured and reported separately.
Messenger, Instagram, and other Meta DM channels are send-capable but not chain candidates beyond their own Meta family: a Messenger hop only works when the recipient has an open Meta conversation, which the generic capability check cannot guarantee. When you encode a chain entry, the router re-validates eligibility per hop — an ineligible entry is rejected at configuration time rather than silently skipped at send time.

​
4. Per-channel capability matrix

One row per channel, every capability from the taxonomy as a column. Yes = the channel carries it; No = it does not, or carries it only in a degenerate form (marked where relevant). Follow the channel link for the send shapes, rate limits, and provider contract. The matrix answers two questions at once: capability (which channels can carry this payload class at all) and fallback eligibility (which of those channels the org-level chain may legitimately descend to). Everything else — the exact request envelope, provider tiers, rate limits, and per-market quirks — belongs to the channel page it links.

​
Where the other models plug in