What the screen actually wires up
The messaging channels screen does one narrow, useful thing: it stores the credentials that let a provider deliver messages to you, and it stores the credentials that let you send replies back. Everything else about the feature — how the conversation is threaded, who it gets assigned to, what the reply looks like — happens in your ticket queue, because an inbound message from any of these channels becomes an ordinary ticket the moment it is accepted.
There are two blocks on the page and they are not interchangeable. The first is Twilio, which carries WhatsApp and SMS. The second is Meta, which carries Messenger and Instagram. Four channels, two sets of credentials, because the channel is worked out from the shape of the payload rather than from anything you configure. A Twilio message whose sender begins with the whatsapp: prefix is filed as WhatsApp; without the prefix the same payload is filed as SMS. On the Meta side the envelope carries an object field, and the value instagram is what separates an Instagram message from a Messenger one.
That is worth knowing before you start, because it means you cannot switch on WhatsApp without also switching on SMS for the same Twilio number, and you cannot take Messenger without Instagram on the same Meta app. The unit of configuration is the provider, not the channel.
Two switches per provider, and they are independent
Each provider block ends with two checkboxes: receive incoming messages, and send agent replies back over this channel. Both are off until you turn them on, and they do genuinely different jobs.
The inbound switch is enforced at the receiver, not in the interface. If it is off, the webhook endpoint does not merely ignore the delivery — it refuses it, answering the provider with a 403 and the message that the channel is not configured for this site. That is the correct behaviour, because silently accepting unverified traffic would be worse, but it does mean a provider console showing repeated delivery failures is often reporting a switch you never turned on rather than a bug.
The outbound switch is checked at reply time. With it off, an agent reply is still saved on the ticket and still emitted as a channel.outbound event for anything you have built on the webhook feed, but nothing is posted to the provider, so the person who messaged you never hears back. That is the single most damaging half-configured state available on this screen: from the inside the queue looks like it is being worked, and from the customer side nobody answered.
Turn both on together, or turn neither on. A channel you can receive but not answer is worse than a channel you never offered.
The webhook URL and the handshake
The page gives you one read-only URL per provider with a copy button. Both point at the same endpoint and differ only in a provider parameter and your site id. You paste the Twilio one into the messaging webhook field for your number in the Twilio console, and the Meta one into the callback URL field in the Meta app dashboard.
Meta then performs a subscription handshake before it will deliver anything. It calls your URL with a mode, a challenge and the verify token, and the endpoint echoes the challenge back only when the token matches the one you saved, compared in constant time. The token itself is yours to choose — any value, as long as the same string is typed into both places. If the handshake fails you get a 403 and no explanation, which is deliberate; the fix is almost always a trailing space or a token saved on one side and not the other.
Twilio has no handshake. It simply starts posting, and the first thing the endpoint does is verify the signature.
Why a correct credential can still fail the signature check
Both providers sign their deliveries and the endpoint rejects anything that does not verify. Meta signs the raw bytes of the request body, which is why the receiver hashes the bytes as they arrived rather than re-serialising the parsed JSON — a re-serialised body produces a different digest and would reject every genuine delivery.
Twilio signs the exact URL it called, and this is the one that bites in practice. If TLS terminates at a proxy or load balancer in front of the application, the request arrives looking like plain HTTP on an internal address, and a signature computed over that URL will never match. The receiver rebuilds the public URL from the forwarded protocol and host headers before checking. So if your signatures fail on a deployment that works elsewhere, look at whether your proxy forwards those headers before you look at the auth token. A non-default port matters too: it is part of the string Twilio signs.
A failed signature returns 403 and the message is dropped. This is the intended outcome for a forged request, and it is also what you will see for a genuine one when the auth token on the screen belongs to a different Twilio account than the number that is calling you.
What actually becomes a ticket
Once a delivery verifies, the receiver looks for something to file. A message with text is obviously a message. A message with only an attachment and no caption is also a complete message — a photo of a damaged item, a receipt, a screenshot — and it is accepted rather than discarded. Up to ten attachments come across from one delivery, and where there is no text the ticket comment reads that the customer sent an attachment, or how many. Message text is stored up to eight thousand characters.
Two categories are deliberately ignored. Delivery receipts and read notifications from Meta carry no message and are skipped. So are echoes: when your own outbound reply comes back through the same subscription, it is marked as an echo and dropped, which is what stops a channel talking to itself.
Providers retry, and a retry must not post the same thing twice, so every inbound message is checked against the provider message id already recorded on a ticket. A replay resolves to the ticket it originally created and is counted as a duplicate rather than added again. The endpoint replies with a small JSON body reporting how many messages it accepted and how many were duplicates, which makes a provider console the easiest place to confirm the wiring works.
How messages get threaded into conversations
A thread is identified by the channel plus the sender identifier — the phone number for WhatsApp and SMS, the platform user id for Messenger and Instagram. When a message arrives, the receiver looks for an open ticket on that thread. If it finds one, the message is appended to it as a comment attributed to the requester. If it does not, a new ticket is created with a subject naming the channel and the sender, status open, priority normal.
The consequence is worth planning for: a thread continues only while its ticket is open or pending. Once it is resolved, the next message from the same person starts a fresh ticket rather than reopening the old one, so a customer who replies two days after you resolved their issue appears as a new conversation with none of the earlier context attached. If that matters to your team, either leave channel tickets open longer than you would leave email ones, or make it a habit to link the two. Our note on snoozing and merging tickets covers the mechanics of stitching them back together.
First contact also binds the sender to a customer identity, so the same phone number or platform handle is recognised next time rather than being treated as a stranger.
What happens when an agent replies
Any comment on a channel ticket that is not attributed to the requester counts as a reply. When one is saved, three things happen in order: a channel.outbound event is emitted for your own integrations, an outbound message is counted against the channel, and the reply is posted to the provider using your stored credentials if outbound is enabled.
The delivery attempt is deliberately soft. The reply is already stored on the ticket before the send is attempted, so a provider outage records a failed delivery status against the comment rather than throwing away the agent message. That is the right trade, and it means the place to look when a customer says they never got an answer is the delivery status on the individual comment, not the ticket as a whole.
The provider hosts are hardcoded constants in the sending code, so nothing stored in your account can redirect these requests somewhere else. Credentials are never written to logs; only the provider error text is kept, which is what you want when you have to paste a failure into a support conversation.
How the credential fields behave
Every secret on this screen is write-only from the browser. The page tells you whether each one is set and shows a short hint — the last four characters — but never returns the value, so a stored credential cannot be read back through the dashboard or captured in a screenshot of it. Leaving a secret field blank means keep what is stored, which is how you toggle a switch without re-typing a token. After a successful save the secret inputs are cleared, so nothing is left sitting in the page.
The Twilio auth token does double duty: it verifies that inbound requests really came from Twilio, and it authenticates your outbound replies. The Meta page access token is only needed for sending. The account SID and your Twilio number are not secrets and are shown normally.
This screen is scoped to the signed-in account throughout — no site identifier is ever accepted from the browser — so an agent cannot read or write another tenant credentials through it. If you want the wider picture of which credentials live where, our guide to securing chat integrations and API keys is the companion piece.
Before you announce the channel
The feature depends on a schema that may not be present on every deployment. Where it is missing, the screen says so plainly and names the script an administrator has to run; saving is blocked rather than silently discarded. Check for that banner before you promise a launch date.
Then prove the round trip rather than assuming it. Message your own number or page from a personal account, watch the ticket appear, reply from the queue, and confirm the reply reaches the phone. That single loop exercises the handshake, the signature check, the threading, the credentials and the outbound switch in one go, and it is the only test that tells you the whole chain works.
Finally, decide the staffing question before the traffic arrives. A messaging channel sets a different expectation from a chat widget: people message and walk away, and they expect to find an answer later rather than to be waited on now. If you cannot cover the hours you are about to advertise, our comparison of live chat and messaging apps is worth reading before you switch anything on. The channels themselves land in the same shared inbox as the rest of your support, which is the point — one queue, several front doors.
Outbound replies on these channels lean on the same delivery machinery as any other subscription, so it is worth knowing what happens when a webhook does not arrive before you need to know it in a hurry.
Once messages are flowing, the volume figures per channel will not match your provider dashboard exactly. How your channel message counts are counted explains the counting rule, the UTC month boundary, and why a count can legitimately go missing.
Media arriving on these channels behaves differently from a file uploaded in chat: it stays with the provider and is fetched on demand. Why the photo a customer sent on WhatsApp opens only in your ticket explains what your agents are actually looking at.