Start free
All posts

WhatsApp opt-in: what the law requires, what Meta requires, and where the two don't meet

Meeting Meta's policy is not meeting data protection law, and meeting the law won't protect you from a quality-based block. Two sets of rules with different foundations — and treating them as one means finding out the difference at the worst moment.

CCX OperationsDelivery · Operations · Aug 25, 2026 · 6 min read
Painting of a desk with a notebook, pen, glasses, coffee and a sealed envelope
Two requirements with different foundations, over the same message. Illustration.

What you'll take away

  • Why “they're already my customer” doesn't settle the opt-in question
  • What Meta measures that the law never mentions
  • How to record consent in a way that survives an audit

Two rules with different foundations

Data protection law is about a lawful basis for processing personal data. Meta's policy is about user experience inside WhatsApp. They overlap substantially, but they aren't the same thing, and the gap is where the trouble lives.

A concrete example: you can hold a solid lawful basis for a message — performance of a contract, say, notifying someone about an order they placed — and still take a quality block if enough people mark your message as unwanted. The law doesn't measure irritation; Meta does.

The reverse happens too. You can have an excellent block rate and still be processing data without an adequate lawful basis, because Meta's metric is not a legal opinion.

What Meta actually watches

Your number's quality is computed from behavioural signals: how often people block, report, or simply never reply. There's no clause you sign that settles it — it's a live indicator, and it moves.

The practical consequence is operational rather than legal: low quality reduces your messaging limit, and the reduced limit lands precisely on the day you need volume. That's why opt-in is worth treating as operational risk control, not just a legal to-do.

What to record, and for how long

Consent without a record is the same as no consent on the day someone asks. The record has to say who consented, when, through which channel and for what purpose — and it has to survive changes to your product.

A detail that often slips: opting out has to be as easy as opting in, and it has to take effect immediately. If someone asks to leave and your next campaign still includes them because the audience was frozen beforehand, the consent record won't save you — and the spam report that follows hits your quality with Meta.

Which is why opt-in is better modelled as a state on the contact, read at send time, than as a static list assembled at some earlier moment.

Where this touches the data subject

Data protection law gives people the right to know what you hold, to correct it, and to ask for erasure. If your conversation history lives in one place and your consent record in another, answering that request becomes a project rather than a query.

Worth designing before you need it: an erasure request with a clock running is the worst moment to discover how many systems someone's phone number ended up in.

The minimum that has to be on record

01Who, when and through whereIdentification of the person, a timestamp, and the channel the consent was given through.
02For what purposeConsent to receive order notifications is not consent to receive promotional campaigns.
03Opt-out with immediate effectState read at send time, not a list frozen beforehand — otherwise leaving only applies to the campaign after next.
See how CCX handles security and privacy

Want to see this running on your own number?

Sign up through the site and get a US$5 test credit.