A WhatsApp opt-out, end to end
A customer writes STOP on its own. Connect marks the conversation opted out, withdraws consent on that person's WhatsApp route, and writes a memory block that every send path already consults. Anything pending for them is refused from that moment, and the decision is in the audit trail. Inbound messages keep arriving.
The stages#
- Trigger — a person writes a stop word and nothing else:
stop,unsubscribe,cancel,end,quit,optout,opt outorrevoke. - External event — Meta delivers that message to the one inbound webhook like any other.
- Authentication and workspace resolution — the signature is checked against the account's app secret, and the workspace that owns the receiving number is resolved.
- Ingest —
process_webhookstores it; nothing about the request is special at this stage. - Canonical record — the message is stored on the conversation. The request is part of the conversation, not a side channel.
- Classification —
_consent_wordapplies the same strict single-word test SMS uses. A sentence containing the word is a message to answer, not an unsubscribe. - Knowledge, memory and rules — existing directives are consulted; a block may already be in force, in which case this is a repeat.
- Autonomy and approval — recording a stop needs no approval. Honouring the request is not a decision a workspace defers.
- Action — three records:
opted_outon the conversation with the moment it happened, consent withdrawn on the person's WhatsApp route sourcedwhatsapp:opt-out, and a memory block tagged for this channel. - Result — every automatic path now refuses before a model is asked, and a held draft can no longer be approved past the block.
- Relationship, timeline and memory — the refusal is part of the relationship and visible on it, not buried in a setting.
- Audit, usage and Needs You — the decision is recorded, and an open commitment to somebody Connect may no longer message is raised for a person.
Stage by stage, with the failures#
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Message arrives | The request on the thread | A stored message | Nothing specific — this is an ordinary inbound message |
| Word tested | Usually a short acknowledgement | The message is or is not a stop | A phrase rather than the word — *please remove me from this list* does not trip the test and needs a person |
| Refusal recorded | The conversation opted out, consent withdrawn on the route | Three records: conversation, route consent, memory block | A request meant for every channel recorded as one channel only |
| Pending work re-evaluated | Held drafts that can no longer be approved | Approval fails, showing the block and its origin | A commitment already promised now cannot be kept |
| Recorded | The decision in the log | Audit row | Nothing — a refusal is recorded as a decision, deliberately |
Choosing the scope of a refusal#
- A STOP on the channel
- The automatic three records. Right when somebody says "stop messaging me here" and still expects an invoice by email.
- A channel suppression recorded by hand
- The same effect for a request that did not arrive as a single word — a sentence, a phone call, an email.
- The memory block itself
- A memory row tagged against the contact, so it holds across every future conversation rather than one thread. A START deactivates it; it is never deleted.
- A do-not-contact entry
- Every channel. The safer reading when somebody asks to be left alone rather than to stop one kind of message — and the Connect Assistant cannot clear one.
Getting this wrong in the narrow direction is the failure that reaches a customer: a person who asked to be left alone entirely, recorded as a WhatsApp stop, gets an email a week later. A do-not-contact reaching every channel is the flow for the broader case.
What it looks like afterwards#
- The Person carries a suppression with a visible origin — what created it, and when.
- Approving a held reply to them fails, showing the suppression rather than a generic error.
- The decision log records the stop, and records later refusals as decisions in their own right.
- If they write again, the message still arrives and is recorded — and a person should read it.
The fourth is deliberate and occasionally surprising. Someone who opted out and then asks a question is asking a question, and losing it because of a suppression would be a worse failure than the one suppression exists to prevent.
Questions#
Does Connect reply to confirm the opt-out?
A short acknowledgement inside the conversation they just wrote in is normally appropriate and permitted. What is not permitted afterwards is a new approach.
Can the stop be undone?
The customer can undo their own by writing START — that reopens the conversation, grants consent on the route again and deactivates the block. A suppression or do-not-contact recorded by a person is treated more carefully, is not cleared casually, and the Assistant has no right to clear one at all.
Does the stop apply to other workspaces on the same deployment?
No. Suppressions are workspace-scoped like every other record. Each workspace holds its own.