WhatsApp Opt-In and Opt-Out Requirements: Meta's Rules and GDPR

Two sets of rules govern whether you may message someone on WhatsApp, and they are related without being identical. Meta requires opt-in as a platform condition; GDPR asks a separate question about your lawful basis. Teams that design one capture surface to satisfy both — and record the result properly — rarely have to revisit the topic.

What Meta requires

Meta's Business Messaging policy requires opt-in before you initiate a conversation, whatever the message is about. In practice a compliant opt-in surface:

• Names your business clearly, using the same name the recipient will see on the WhatsApp thread.
• States explicitly that messages arrive on WhatsApp — not just "we'll be in touch".
• Describes the type of messages being agreed to, so order updates and promotions are distinguishable.
• Requires an affirmative action from the person: a tick, a tap, a message sent to your number.

Failing this is not primarily a legal risk — it is an account risk. Blocks and "not useful" reports drive quality rating down, and a poor rating throttles your messaging limits before anyone writes to a regulator.

What GDPR requires

GDPR does not ask "did they opt in?" It asks what your lawful basis is for the processing, and separately whether direct marketing rules apply. Where consent is the basis, it must be:

• Freely given — not bundled into terms of service or made a condition of an unrelated purchase.
• Specific and granular — separate agreement per purpose. Service notifications and marketing are two decisions, not one.
• Informed — who is processing, for what, and where to find the privacy notice.
• Unambiguous — a clear affirmative act, never a pre-ticked box or silence.
• Withdrawable — as easily as it was given, and effective immediately.
• Demonstrable — Article 7(1) puts the burden of proof on you.

Transactional messages often rest on contract performance rather than consent, which is legitimate — but Meta still wants the opt-in, and the moment a transactional template carries a promotion the basis has quietly changed underneath you.

Where opt-in actually gets captured

• QR codes and click-to-chat links. The person sends the first message, which is a strong affirmative act. Put the disclosure on the poster or landing page beside the code, not only in the auto-reply — see the docs on QR opt-in.
• Web forms and checkout. A separate unticked box per purpose, with the WhatsApp wording visible next to it rather than buried in linked terms.
• In-conversation upgrade. Someone who messaged you about an order has not agreed to marketing; ask inside the thread and record the reply as its own consent event.
• Existing databases. Consent collected for email does not transfer to WhatsApp. Re-permission rather than assume.

Honouring opt-out

Make stopping easy: an obvious instruction, recognition of the common phrasings ("STOP", "unsubscribe", "no more messages"), and a quick-reply button on marketing templates. Then enforce it at send time. Suppression that lives in a campaign list rather than the contact record is the classic failure — the next campaign, built from a different segment, messages them again.

Log the withdrawal as an event with its timestamp and source. You need it both to prove you acted and to explain, if the same person later opts back in, why messaging resumed.

Why an append-only ledger is the clean answer

A boolean flag on the contact row records state; it does not record history. An append-only consent ledger stores each grant and withdrawal as its own immutable row — contact, channel, purpose, source, timestamp — and derives the current state from the latest event. That gives you three things at once: a defence under Article 7(1), an audit trail that satisfies Article 30, and a single enforcement point every send path reads. The implementation is covered in the docs on consent and opt-in.

On a single-tenant instance the ledger is in your own database, which means erasure requests can genuinely remove the contact while the consent evidence retention policy you chose still applies to the record of the decision — a distinction that is hard to make on a shared platform.

The short version

Design one capture surface that names you, says WhatsApp, and separates purposes. Record every grant and withdrawal as an event. Enforce suppression at send time, not at list-build time. Do that and both Meta's policy and the GDPR question are answered by the same piece of infrastructure. For the wider picture, start with the GDPR position on WhatsApp.