Facebook Messenger is Meta's first messaging channel to hit a billion monthly users, and it ships on Devotel Orbit as a first-class, standalone channel — its own connect card under Settings → Channels, its own workspace slice under Messages, its own inbound webhook scope. The sibling post Instagram DM and Messenger as support channels covers the two Meta DM surfaces side by side and decides whether either earns a place in your stack. This guide assumes you already run Messenger — or are about to — and goes one level down: the channel family split, the exact inbound envelope, the 24-hour window and the opt-in shapes that govern out-of-window replies, and the pairing decision with WhatsApp.
The send mechanics — payload fields, error codes, SDK calls — live in the Messenger channel docs. This post is the operator's model of the channel, not an API reference.
Three Meta surfaces, and why only two are messaging channels
"Meta messaging" is a loose grouping, not a channel. Three surfaces matter to an operator, and they are not interchangeable.
- Facebook Messenger is page-attached. Your Facebook Page is the channel's identity, conversations open from the Page's Send Message button, from m.me short links you publish, and from Click-to-Messenger ad placements. The recipient addresses you as a PSID — a Page-Scoped ID that exists only in the context of your Page.
- Instagram DM is business-account-attached. The identity is the Instagram business account, and the recipient address is an IGSID. Different identity model, different entry points (comment-to-DM, story replies), same underlying Messenger Platform plumbing.
- Meta Business Suite is Meta's own inbox product grouping Page and account surfaces behind one login. It is not a third messaging channel and not an API surface — it is how a small business reads DMs without an API at all. The moment you connect Messenger to Devotel Orbit, the Business Suite inbox becomes a parallel view, not the system of record.
The operator's takeaway: Messenger and Instagram DM are separate live channels on Orbit with separate connect cards and separate addressing schemes. "Meta Business Suite" deployments do not block an API integration — they just stop being where agents work.
The channel:"messenger" inbound envelope — what actually arrives
Every inbound Messenger message POSTs the standard Orbit message envelope to your registered webhook, scoped by channel: "messenger". Three shapes matter.
A text message carries message.text plus the sender's PSID in message.from. An attachment message carries message.attachments[] with typed URLs — the same envelope, no text key. An opt-in plugin event (Meta's consent prompt confirmed by the recipient) arrives as message.received with metadata.opt_in: true — and it is processed server-side to update the recipient's consent record rather than dispatched outward as an automation trigger. Do not build webhook consumers that wait on opt-in events; treat them as consent-state updates Orbit maintains for you.
Two rules keep integrators honest on this surface. First, the PSID is the address. Capture message.from from the first inbound event onto the contact record — that value is the to of every outbound send you make afterward. Second, postbacks and referrals never leave Orbit's envelope. Button taps and m.me/ad referrals are processed internally (a button tap becomes an inbound message in the conversation timeline; a referral attaches to attribution), but they are not dispatched to your webhook. React to them in Orbit-side flows, not in webhook filters.
In the dashboard the same normalization applies: inbound Messenger traffic lands in the unified inbox on the same envelope as SMS, WhatsApp, and web chat, so routing, assignment, and SLA clocks behave identically. When a thread needs a human now, it surfaces through the Live tab of the AI-agents workspace alongside every other channel.
The 24-hour window — and the opt-in shapes that govern your reply model
Meta's customer-service window is the operational constraint on Messenger. A recipient's inbound message opens a 24-hour window; inside it, free-form replies pass. After it closes, three exits remain, and each is a tenant-owned control, not a Meta loophole.
- Tagged sends. A
MESSAGE_TAGsend carrying a Meta-approved tag passes outside the window — account updates, post-purchase status, confirmed-event updates — and the human-agent class extends support follow-ups to a 7-day horizon. A tag Meta did not approve, or a tagged send with no tag, fails closed with a named reason instead of a silent drop. On Orbit, the Messenger send path pre-checks the window before dispatch, so a returned success means the message was actually deliverable — never an illusion of delivery for a message Meta then discarded. - One-time notification tokens. An OTN request sent inside an open window asks the recipient for a single follow-up; their tap attaches a token to the PSID that a later send can spend once, even after the window closes. This is the issue-type opt-in — one consent, one message, consumed on use.
- Subscription opt-in. The opt-in plugin event with
metadata.opt_in: trueis the subscription-shape consent: the recipient confirms an ongoing relationship, and the consent record is updated server-side. Your tenant owns which consent prompt to render and when; Orbit owns the record of their answer.
The tenant-owned controls sit on your side of the line: which tag class is legitimate for a given follow-up, when to ask for an OTN token versus a subscription opt-in, and what SLA targets you set against the window. Discipline that works whichever shape you pick: respond inside business hours well before the window closes, and frame DM SLAs against the window rather than the workday.
Pairing with WhatsApp — when the conversation moves
Messenger and WhatsApp are both Meta first-party channels on Orbit, and the pairing decision is a routing decision, not a funnel the channel owns. Three operator rules cover the common cases.
- Stay on Messenger when the thread is short-horizon, when the entry point was a Page surface or an ad placement, and when the recipient's PSID is the only identifier you hold. Messenger is inbound-led, and for public-surface brands it is often the only impression of the customer you have.
- Move to a WhatsApp template when the case needs a multi-day back-and-forth the Messenger window cannot carry, and you have a verified phone number on the contact record. WhatsApp's template model supports outbound reactivation across days in a way Messenger's tagged classes do not — the hand-off keeps the contact and conversation thread visible in the unified inbox.
- Let the recipient choose when a quiet thread needs reactivation and both identifiers exist: an OTN prompt on Messenger asks for one more message; a WhatsApp template asks to continue on the channel Meta treats as their primary messaging surface. Either is a legitimate, consented re-entry — the routing picks the one the contact is most likely to answer.
What the pairing is not: a fallback chain that escapes Meta. Meta messaging terminates at Meta — there is no carrier route behind a DM — and the always-on fallback for any Meta-channel program remains SMS, the same conclusion the channel fallback matrix draws across every messaging channel.
Frequently asked questions
Is Messenger one channel, or part of a Meta bundle?
One standalone channel. Instagram DM is a separate live channel on Orbit (business-account identity, IGSID addressing), and Meta Business Suite is Meta's own inbox product, not an API surface. This guide is the Messenger-specific operator companion to the joint Instagram DM and Messenger post.
What does an inbound Messenger webhook actually contain?
The standard Orbit envelope scoped channel: "messenger": event: "message.received", message.text or message.attachments[], and the sender's PSID in message.from — the value you capture as the to of every outbound send. Opt-in plugin events arrive with metadata.opt_in: true and update the consent record server-side.
Can Orbit message a recipient who never messaged us first?
No — that is Meta's rule, not Orbit's. Messenger is inbound-led: the recipient starts the thread, and outbound replies pass inside the 24-hour window. After the window, only a Meta-approved tagged send, a human-agent follow-up, or a spent OTN token goes through, and the send path fails closed with a named reason when neither applies.
When does a Messenger conversation belong on WhatsApp instead?
When the case needs days of back-and-forth and you hold a verified phone number for the contact. WhatsApp templates reactivate a quiet thread across days; Messenger's tagged classes and OTN tokens cover shorter follow-ups. The hand-off keeps the contact record and conversation thread in the same unified inbox.
Do postbacks and referral clicks reach my webhook?
No. Button taps and m.me/ad referrals are processed inside Orbit — taps become inbound messages in the conversation timeline, referrals attach to attribution — but they are not dispatched as webhook events, so build reactions in Orbit-side flows.
The takeaway
Facebook Messenger on Devotel Orbit is a standalone first-class channel, not half of a bundle post: page-attached identity, PSID addressing, and an inbound envelope that normalizes into the same unified inbox and contact record as every other channel. The 24-hour customer-service window is the constraint your reply model works inside, and the tenant-owned exits — tagged sends, OTN tokens, subscription opt-ins — are chosen by you and enforced by the send path so a returned success is a delivered message. Pair it with WhatsApp when a thread needs days, keep SMS as the always-on fallback, and read the channel docs for the payload-level mechanics. The joint Instagram DM and Messenger post is the paired reading for the two-surface decision; this guide is the Messenger-specific operating model.
Published 28 September 2026.