> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Messages hub orientation — the tile map for every channel console > A map of the Messages hub — the per-channel consoles, the cross-channel tables, Notify cascades, commerce rails, and message settings — what each tile answers on a first visit, who can open it, the walkthrough order that works with its skip conditions, and links to the in-depth guides behind each console. # Messages hub orientation — the tile map for every channel console The Messages docs split coverage by surface — one page per channel under Channels, plus a long list of individual guides — because that is how the features shipped. Operators do not work that way. The question that brings someone to `/messages` is one sentence: *where do I run a channel?* This page answers it, collecting every tile on the **Messages** hub in the dashboard into one walkthrough. Every console below is a tenant-owned control — you set it for your workspace, and nothing applies until you turn it on. Each tile maps 1:1 to a route under `/messages` in the dashboard. ## Why the hub is a map The Messages hub groups three kinds of surface: the **channel consoles** where you send and read traffic per channel (SMS, MMS, RCS, WhatsApp, email, fax, push, the social messengers, the owned channels), the **cross-channel tables** that hold one view over every channel at once (templates, batch, scheduled, delivery log, blocklist, landing pages, feedback), and the **rail-level surfaces** — Notify fan-out, commerce, and routing settings — that sit underneath the channel consoles and steer them. One question brings an operator here — *where do I run a channel?* — and the hub answers it in two rows: pick the channel console above, then manage the cross-cutting tables below it. Old `/channels` bookmarks still reach the same hub ([see The bare /channels redirect](#the-bare-channels-redirect)). ## Channel consoles Each channel console is the working surface for one channel: compose, send, inspect the delivery log filtered to that channel, and read its connection state. The hub card shows the channel's rolling-24h Sent and Delivered counters and a status dot — Connected, Degraded, Down, Not configured, Pending verification (Email with a custom sending domain still finishing DNS checks), or Coming soon. ### SMS — `/messages/sms` What it answers: *how do I send, read, and count SMS over my registered sender identities?* Open this first — every other channel console reuses its shape (compose box, log, KPI row, filter presets). The console surfaces 10DLC/toll-free sender state beside the compose flow, so a compliance gap shows before a send fails. First visit: with no sender registered the console routes you to the sender-onboarding flow before the compose box unlocks. Docs: [SMS channel page](/channels/sms); [Send and receive messages](/guides/send-receive-messages); [First SMS end to end](/guides/first-sms-end-to-end); [Two-way conversation](/guides/sms-two-way-conversation). ### MMS — `/messages/mms` What it answers: *how do I send media-rich messages, and which of my sends carried attachments?* Same console shape as SMS plus media handling. Skip when your traffic is text-only — SMS covers it. Docs: [MMS channel page](/channels/mms); [MMS send and receive](/guides/mms-send-and-receive); [MMS media-rich content](/guides/mms-media-rich-content). ### RCS — `/messages/rcs` (+ `/brands`, `/builder`, `/setup`) What it answers: *where do I run branded rich messaging — agents, rich cards, and the verification state of each brand?* The console splits into the send surface and three sub-consoles: **brands** (register and track agent/brand verification), **builder** (compose rich cards visually), and **setup** (the agent provisioning wizard). First visit: until a brand passes carrier verification the rich surfaces stay preview-only — run the setup wizard first. Skip when you only need plain text — SMS carries it without brand onboarding. Docs: [RCS channel page](/channels/rcs); [RCS onboarding](/guides/rcs-onboarding); [RCS setup wizard](/guides/rcs-setup-wizard); [RCS brands console](/guides/rcs-brands-console); [RCS rich card builder](/guides/rcs-rich-card-builder). ### WhatsApp — `/messages/whatsapp` (+ `/flows/[id]/edit`) What it answers: *how do template messages, session replies, and WhatsApp Flows come together on one number?* The console handles template sends and the delivery log; the **flows/\[id]/edit** sub-route is the visual editor for interactive Flows attached to your WABA. First visit: until a WhatsApp Business sender is connected the console shows the connect flow. Skip when WhatsApp is not in your channel mix. Docs: [WhatsApp channel page](/channels/whatsapp). ### Email — `/messages/email` (+ `/builder`) What it answers: *where do transactional and bulk email sends run, and where do I design the body without HTML?* The console is the send + log surface; **builder** is the drag-and-drop visual editor that writes the template the send uses. First visit: a custom sending domain shows Pending verification until its DNS records pass — sends still work on the shared default domain meanwhile. Skip when you only send via SMTP relay — that surface has its own guide. Docs: [Email channel page](/channels/email); [Email lifecycle guide](/guides/email-lifecycle-guide); [Email visual builder](/guides/email-visual-builder); [SMTP relay](/channels/email-smtp-relay). ### Fax — `/messages/fax` What it answers: *how do I send and receive faxes over the same contact base?* Console is the send surface plus the inbound fax log. Skip when fax is out of scope — nothing else depends on it. Docs: [Fax channel page](/channels/fax); [Fax send workflow](/guides/fax-send-workflow); [Inbound fax workflow](/guides/inbound-fax-workflow). ### Push — `/messages/push` (+ `/manage/*`) What it answers: *where do I send device push, and where do the device tokens, categories, Live Activities, and scheduled pushes live?* The console is the composer; the **manage** sub-consoles cover `device-tokens` (register/prune the installed-device registry), `live-activities` (iOS Live Activity pushes), `notification-categories` (action buttons), and `scheduled-pushes` (queued push dispatch). First visit: with no device tokens registered the composer has nothing to target — integrate the SDK first. Skip when your product has no app surface. Docs: [Push channel page](/channels/push); [Push integration](/guides/push-integration); [Device tokens and scheduled sends](/guides/push-device-tokens-and-scheduled-sends); [Live Activities](/guides/push-live-activities); [Notification categories](/guides/push-notification-categories). ### Social messengers — `/messages/messenger`, `/messages/instagram`, `/messages/telegram`, `/messages/line`, `/messages/kakao`, `/messages/viber`, `/messages/wechat`, `/messages/zalo` What they answer: *where do I run each social-channel conversation?* Each is its own console with the same shape; each onboards through the channel's provider connect flow (Messenger/Instagram via Meta, the APAC channels via their regional providers). First visit: each console routes to the channel's onboarding guide until the sender is connected. Skip the consoles whose channels are not in your mix — nothing else depends on them. Docs: [Messenger](/channels/messenger) with [onboarding](/guides/messenger-onboarding); [Instagram](/channels/instagram) with [onboarding](/guides/instagram-onboarding); [Telegram](/channels/telegram) with [onboarding](/guides/telegram-onboarding); [LINE](/channels/line) with [onboarding](/guides/line-onboarding); [KakaoTalk](/channels/kakao) with [production patterns](/guides/kakao-production-patterns); [Viber](/channels/viber) with the [upgrade guide](/guides/viber-upgrade); [WeChat](/channels/wechat) with [onboarding](/guides/wechat-onboarding); [Zalo](/channels/zalo) with [onboarding](/guides/zalo-onboarding). Regional rollups: [Asia](/guides/asia-channels-onboarding), [LATAM](/guides/latam-channels-onboarding), [MENA](/guides/mena-channels-onboarding), [Europe](/guides/europe-channels-onboarding). ### Apple Messages — `/messages/apple` What it answers: *where do Apple Messages for Business conversations and commerce checkouts run?* The console carries the business-id agent and its message log. First visit: the console is empty until the Apple agent is registered. Skip when iOS-native messaging is not in scope. Docs: [Apple Messages for Business onboarding](/guides/apple-messages-for-business-onboarding); [Apple Messages commerce checkout](/guides/apple-messages-commerce-checkout). ### In-App Messages — `/messages/in-app` What it answers: *where do I author the owned, zero-carrier-cost cards my web and React Native SDKs render?* The console holds the channel's master switch and the content-cards editor; SDKs pull the assembled feed from the SDK endpoint. First visit: the editor opens with the channel disabled — author cards, then flip the switch. Skip when your product has no embedded surface. (The tile lives in the hub's **Owned channels** tools group, alongside Web Chat.) Docs: [In-app channel messages](/guides/in-app-channel-messages). ## Cross-channel tables These consoles sit one level above the per-channel pages: each holds one table over every channel at once. Use them after at least one channel console is live — until then they are empty lists. ### Templates — `/messages/templates` What it answers: *which reusable message bodies exist, in which languages, and what approval state are they in?* Templates span SMS, WhatsApp, RCS, and Email with variable substitution. Docs: [Outbound templates](/guides/outbound-templates); [Template analytics](/guides/template-analytics); [RCS templates tab](/guides/rcs-templates-tab). ### Batch — `/messages/batch` (+ `/batch/drafts`) What it answers: *how do I send one message to an ad-hoc pasted list, and where are my unfinished batches?* Paste, validate, dispatch — outside the campaign lifecycle. Drafts hold uploaded lists you have not dispatched yet. Docs: [Batch send guide](/guides/messages-batch-sms). ### Scheduled — `/messages/scheduled` What it answers: *which messages are waiting to dispatch, and can I reschedule, edit the body, or cancel them?* The queued-send management surface. Docs: [Message scheduling](/guides/message-scheduling). ### Delivery log — `/messages/delivery-log` What it answers: *where did any message go, across every channel at once?* Cross-channel search over sender, recipient, body text, and provider reference — the per-channel consoles only scope one channel each, so this is the lookup surface for support and reconciliation. Docs: [Delivery logs guide](/guides/developer-delivery-logs); [Delivery log console](/guides/delivery-log). ### Blocklist — `/messages/blocklist` What it answers: *which destinations are blocked from outbound sends on every channel?* Self-service suppression for bad-actor numbers. Docs: [Blocklist guide](/guides/messages-blocklist). ### Landing pages — `/messages/landing-pages` What it answers: *which hosted landing pages back my message links, and what do they convert?* The page builder for the web destinations short links resolve to. Docs: [Landing pages guide](/guides/landing-pages). ### Feedback — `/messages/feedback` What it answers: *how do conversion outcomes (confirmed / unconfirmed) come back into message records from an external attribution export?* Bulk-import surface for up to 1000 messages at a time. Docs: [Message feedback bulk import](/guides/message-feedback-bulk-import). ## Notify and cascades ### Notify — `/messages/notify` What it answers: *how do I reach one recipient on several channels at once — or walk them down an ordered fallback chain until one channel delivers?* The composer fans a payload out across SMS, WhatsApp, RCS, email, push, and more, either all at once or as a waterfall cascade (for example RCS → WhatsApp → SMS) that stops at the first delivery. First visit: with no channels connected it composes nothing — run one channel console first. Docs: [Multi-channel notify](/guides/multi-channel-notify); [Cascade failover](/guides/notify-cascade-failover); [Track a cascade](/guides/track-a-cascade); [Cascade cost model](/concepts/notify-cascade-cost-model). ## Commerce Six rails close the loop from a message to a payment. Each is a tenant-owned console under `/messages/commerce`; none applies until you configure it. ### Pay-by-link — `/messages/commerce/pay-links` What it answers: *how do I mint a tokenized hosted payment link, preview it per channel, drive its lifecycle, and reconcile the PSP capture?* The payment-request center for in-conversation checkout. Docs: [Commerce: DCB and pay links](/guides/commerce-dcb-and-pay-links); [Conversational commerce checkout](/guides/conversational-commerce-checkout). ### Direct Carrier Billing — `/messages/commerce/dcb` What it answers: *how do operator-billed checkouts (EMEA/MENA digital goods) onboard, charge, refund, and reconcile settlement?* Docs: [Commerce: DCB and pay links](/guides/commerce-dcb-and-pay-links). ### Subscriptions — `/messages/commerce/subscriptions` What it answers: *how do recurring orders start off an existing cart, and where do pauses, resumes, and next-renewal dates live?* Docs: [Subscriptions, storefront, and mandates](/guides/commerce-subscriptions-storefront-mandates). ### Agentic storefront — `/messages/commerce/storefront` What it answers: *what does a third-party AI shopping agent see when it discovers my catalog — and is the public storefront published?* Docs: [Subscriptions, storefront, and mandates](/guides/commerce-subscriptions-storefront-mandates). ### Agent payment mandates — `/messages/commerce/agent-mandate` What it answers: *which scoped, spend-capped, revocable consents let an AI agent transact on a customer's behalf — and can I verify and revoke them?* Docs: [Subscriptions, storefront, and mandates](/guides/commerce-subscriptions-storefront-mandates). ## Settings Three controls steer routing rather than messages themselves. ### Inbound routes — `/messages/settings/inbound-routes` What it answers: *where does inbound SMS land — webhook, queue, inbox, or team — matched by number, sender, keyword, or regex?* Rules run in priority order, the messaging analogue of inbound email routing. Docs: [Routing rules](/guides/routing-rules). ### Route quality — `/messages/settings/route-quality` What it answers: *which outbound route is degrading, and when does the circuit breaker fail traffic over to the next one?* The route-health runbook surface. Docs: [Route quality circuit-breaker runbook](/guides/route-quality-circuit-breaker-runbook); [Routing rules](/guides/routing-rules). ### Sender pools — `/settings/channels/sms/sender-pools` What it answers: *how do sends distribute across my pool of sender identities, and which pool member carries what share?* Lives under SMS channel settings in the dashboard. Docs: [Sender pools](/guides/sender-pools). ## Role gating The hub itself renders for owner, admin, and developer seats; viewers and agents do not see `/messages` in the sidebar. * **Channel consoles (read)** — list and detail views accept an authenticated dashboard session, or an API key with `messages:read`. * **Channel consoles (write)** — compose, send, reschedule, cancel, and template management require a workspace role with send permission, or an API key with `messages:write`; a key minted with only `messages:read` is rejected with a 403 on send endpoints regardless of the key's other permissions. The exact scope each endpoint checks is listed per operation in the API reference. * **Inbound routes and route quality** — configuration changes follow dashboard workspace-role rules; reads accept authenticated sessions. * **Tenant isolation** — every console here is tenant-owned: templates, logs, blocklists, routes, mandates, and pools live in your workspace only, nothing crosses tenant boundaries, and nothing applies until you create it. ## Suggested walkthrough order Take the consoles in this order when you stand the surfaces up for the first time: 1. **One channel console** — SMS if your traffic is plain text, WhatsApp if it is not, Email if you are transactional-only. That is the working surface every other console's shape reuses. *Skip when:* a connected channel already exists — start at step 2. 2. **Templates** — define the reusable bodies for the channel you just stood up. *Skip when:* sends are all ad-hoc. 3. **Batch and Scheduled** — move from single sends to lists and queued dispatch. *Skip when:* your traffic is all API-driven. 4. **Delivery log + Blocklist** — wire the reconciliation and suppression loops, then run support lookups there, not in the per-channel pages. 5. **Notify** — only if more than one channel is live; a cascade with one channel is a send with extra steps. 6. **Commerce** — only if checkout-in-message is in scope for the quarter. 7. **Settings (inbound routes, route quality, sender pools)** — last, once real traffic exists to route and measure. Steps 1–4 unblock day-to-day operation. Steps 5–7 are the rail-level work you add once the basics are boring. ## The bare /channels redirect The bare `/channels` path holds no page of its own and always resolves to `/messages` — the canonical hub. It exists so older bookmarks and links from outside the dashboard land somewhere instead of 404ing; the redirect is a pass-through, not a placeholder. Bookmark the console you actually use, not the bare path. ## Hub tiles at a glance Send and inspect SMS traffic — the console shape every other channel reuses. Template and session messaging plus the Flows editor on your WABA number. Branded rich messaging — brands, rich-card builder, and the setup wizard. Transactional and bulk sends, plus the drag-and-drop visual body builder. Reusable bodies across SMS, WhatsApp, RCS, and email — variables and approval state. Cross-channel lookup over every message — sender, recipient, body, and provider reference. Fan one payload across channels, or cascade recipients down an ordered fallback chain. Pay-by-link, direct carrier billing, subscriptions, storefront, and agent mandates. Land inbound SMS on a webhook, queue, inbox, or team by number, sender, keyword, or regex. Watch route health and let the circuit breaker fail traffic onto the next route. ## Where the in-depth docs live * [Channels](/channels/sms) — the per-channel pages under the Channels group are the detailed reference for each console's provider contract. * [Send and receive messages](/guides/send-receive-messages) — the end-to-end send/read pipeline, channel-neutral. * [Guides](#suggested-walkthrough-order) — the granular walkthroughs linked per console above; the Guides nav groups them by task rather than by hub tile. ## See also * [Marketing hub console map](/guides/marketing-hub-consoles) — the same console-map treatment for wallet passes, loyalty, and referrals. * [Developer hub overview](/guides/developer-hub-overview) — the API-side orientation page. * [Inbox settings map](/inbox/settings-map) — the console map for the Inbox settings surfaces. * [Audience hub orientation](/guides/audience-hub-orientation) — the hub map for contacts and audiences. * [Dashboard home walkthrough](/guides/dashboard-home) — the triage surface that links into this hub.