Opt-out on WhatsApp: what Meta requires and what it does not

Meta requires two things about consent, and neither is a keyword. You must hold opt-in permission before you message someone, and you must honour any request to stop, on WhatsApp or anywhere else. Nothing on the Meta pages we read on 19 September 2026 mandates a keyword, a footer line, or the word STOP.

The two sentences that carry the obligation

The WhatsApp Business Messaging Policy states the opt-in rule in its Create a Quality Experience section:

You may only contact people on WhatsApp if: (a) they have given you their mobile phone number; and (b) you have received opt-in permission from the recipient confirming that they wish to receive subsequent messages or calls from you.

The opt-out rule follows a little below it:

You must respect all requests (either on or off WhatsApp) by a person to block, discontinue, or otherwise opt out of communications from you via WhatsApp, including removing that person from your contacts list.

Read the second one closely. A request binds you whether it arrives on WhatsApp or not, so a phone call or an email counts. Block, discontinue and opt out are one request. You must remove the person from your contacts list, not merely suppress the next send. And no format is prescribed: Meta never says how a request must be phrased for you to be bound by it, which is why compliance cannot be narrowed to one keyword.

This is contractual, not advisory. The WhatsApp Business Solution Terms, last modified March 6, 2026, incorporate the policy: “You agree to use the WhatsApp Business Solution in compliance with” the documentation and the Messaging Policy.

Meta hands the method back to you

The policy declines to specify how you collect consent:

You are solely responsible for determining the method of opt-in, that you have obtained opt-in in a manner that complies with laws applicable to your communications, and that you have otherwise provided notices and obtained permissions that are required under applicable law.

Meta’s Get opt-in for WhatsApp page, updated Jun 16, 2026, repeats that and lists the three requirements that do exist. Two are quotable whole: “Businesses must clearly state that a person is opting in to receive communication from the business”, and “Businesses must comply with applicable law”. The third requires you to name the business being opted in to.

Two details there are worth reading twice. Consent need not mention WhatsApp: Meta describes opt-in “which can be general and not specifically for WhatsApp, as long as businesses comply with all local laws”. And the channel is open, from SMS to “In person or on paper (customers can sign a physical document to opt in)”, because “As long as the opt-in method meets the above requirements, it will be policy compliant.”

The policy’s best-practice list is the nearest thing in it to a keyword rule, and it is not one. It suggests “Provide clear instructions for how people can opt out of receiving specific categories of messages or calls, and honor these requests”, under a heading Meta calls Best Practices, beside “Obtaining a separate opt-in to initiate a call to a user”.

The marketing opt-out is a platform feature, not a keyword you handle

For marketing template messages, Meta ships the opt-out itself. Its Marketing templates page, updated Jun 17, 2026, describes a WhatsApp setting that lets a user do one thing in particular: “to stop or resume delivery of marketing messages from your business entirely”. Enforcement is on Meta’s side of the wire:

If you attempt to send a marketing template to a WhatsApp user who has stopped marketing template messages from your business, the API will process the request but not send the message.

You get a failed status webhook, code 131050, titled “Unable to deliver the message. This recipient has chosen to stop receiving marketing messages on WhatsApp from your business”. A user_preferences webhook reports the state change, with one limit: “Only stop and resume actions trigger the webhook.”

So for marketing, a keyword handler you write duplicates a control the platform already runs. Not pointless, because only you can honour a request made off WhatsApp. But the keyword is your design decision, not Meta’s rule.

Blocking is the customer’s own exit, and it has an API

Meta’s Block users page, updated Jun 26, 2026, states the effect of a block:

The user cannot contact your business or see that you are online.

Your business cannot message the user. Attempts to message a blocked user return an error.

A business can block too, within limits: “You can only block users that have messaged your business in the last 24 hours”, and “The blocklist has a 64,000 user limit”. The first is the customer service window showing through, so the block API is no suppression list for outbound.

What getting it wrong actually costs

Meta publishes no penalty schedule for opt-out failures and we are not going to invent one. It does publish the mechanism. From the opt-in page: “People can also block or report a business”, and “Our systems will rate limit businesses” whose quality stays low. That page also advises that “Businesses should monitor quality rating, especially when rolling out new opt-in methods”.

Two different quality ratings are documented, and they are worth keeping apart. One is per template: “Every template has a quality rating based on usage, customer feedback, and engagement.” A RED rating means “The template has received negative feedback from multiple WhatsApp users, or low read-rates”. Ratings feed template pacing and pausing, “which can affect template delivery”, and “If a template continuously receives negative feedback or low engagement” its status can change, after which it cannot be sent.

The other is not about templates at all. The rate limit on the opt-in page is described as a consequence of “the business’s quality”, and Meta’s Service messages page defines a message quality score over your sending generally:

WhatsApp determines message quality from how WhatsApp users have received your messages over the past seven days, weighted by recency. It bases this score on user feedback signals such as blocks, reports, mutes, archives, and reasons users provide when they block you.

That page is about the free-form messages you send inside an open window, and it names where the number surfaces: a WhatsApp Manager panel that “displays your business phone number’s status”, alongside its quality rating and messaging limits. So replies carry quality signals too. A reply that gets you blocked, reported, muted or archived counts, and the same page asks you to “Only send messages to WhatsApp users who have opted into receiving messages from your business.”

Meta publishes no formula connecting a block to a rating change and we have not measured one. The documented chain is only that feedback and blocks feed quality, and quality feeds delivery.

Everything above is Meta’s platform obligation, enforced by WhatsApp, which is the party that can throttle or close you. It is not your legal obligation. Meta puts the burden of “laws applicable to your communications” on you, twice.

We are not going to summarise consent law here. It varies by the country your customer is in, it does not reduce to a checklist, and a page that got it slightly wrong would be worse than no page. Check your own jurisdiction, and read Meta’s requirements as a floor rather than a ceiling.

Why this is structurally smaller for a tool that never sends first

Some of the obligations above are written about initiating and some are not, and the difference is in the policy’s own wording rather than in ours. The opt-in sentence is about contact: “You may only contact people on WhatsApp if” the two conditions hold, and the policy’s separate sentence about replying is the one that names a template exception rather than a consent exception, “You may reply to a user message without use of a Message Template as long as it’s within 24 hours of the last user message”. The marketing stop control is written about marketing template messages specifically. The block API is written about attempts to message a blocked user.

Two things are narrower for a system that never sends first, and one is not. There is no marketing template to be stopped, because there is no marketing template. Template quality rating does not apply to a message that is not a template. But message quality does: the Service messages page scores the free-form replies themselves, so replying badly is a quality event the same way sending badly is.

Consent is the one to be careful about, because reply-only is not a documented exemption from it. Nothing on the pages cited below says that a business which only ever replies needs no opt-in, and the Service messages page points the other way, asking businesses to “Only send messages to WhatsApp users who have opted into receiving messages from your business” in a section about what you send inside an open window. What the inbound message establishes is the real question, and Meta does not answer it in a sentence we found.

The duty to honour a stop request survives whatever the answer is, because the policy covers requests made anywhere and someone can ask you to stop replying. mesej never messages anyone first, which narrows the surface, and no channel is connected to it today, so nothing here has answered a customer. It is not an exemption, and the last three paragraphs are our reading of the pages cited below rather than statements Meta makes.

Google publishes a comparable rule in a comparable place, where a reply’s rejection reason exists in an API and not in the dashboard: the mechanics are here. The same question applies to any tool acting for you: what it does when it cannot.

One note for anyone checking this. business.whatsapp.com/policy returned a 301 to whatsappbusiness.com/policy/, and the Meta developer pages return HTTP 400 to a plain fetch and 200 with browser headers.