What WhatsApp Actually Requires From an Opt-In

What does Meta's opt-in rule actually say?

Meta's rule for who a business may contact on WhatsApp is short, and most of the vendor advice written about it is longer than the rule itself. The developer documentation states that businesses "may contact people on WhatsApp if: (a) they have given their mobile phone number; and (b) businesses have received opt-in permission from the recipient confirming that they wish to receive subsequent messages or calls from a particular business" (Meta - Getting Opt-In).

Two things sit inside that sentence, and only two: a phone number, and a confirmation that the person wants to hear from this specific business again. Nothing in it says the confirmation has to mention WhatsApp. Nothing in it says the number has to have been collected after the business started using WhatsApp. It is a narrower rule than most of the pages ranking for this question suggest, and the narrowness is the point - it is the reason a general opt-in a business already collects for other purposes can, in most cases, also cover WhatsApp.

The same page goes further and settles the point directly: opt-in "can be general and not specifically for WhatsApp, as long as businesses comply with all local laws" (Meta - Getting Opt-In). That clause - "as long as" - is doing real work, and it is the condition the rest of this piece keeps coming back to. Meta is describing its own platform floor, not issuing a blanket permission slip. Whether a given business's general opt-in actually complies with the law in the country its customers live in is a separate question, answered by that country's law rather than by Meta's documentation.

Checked against Meta's documentation on 4 September 2026.

• What does Meta's opt-in rule actually say?
• Does an opt-in have to mention WhatsApp by name?
• What two things must every opt-in wording contain?
• What does a compliant opt-in look like on a website form?
• Can you message a list collected before you had WhatsApp?
• Where does local law override Meta's minimum?
• How do you import a customer list without losing rows?
• Why do spreadsheets from Excel break contact imports?
• What should you store so an opt-in can be proved later?
• What happens when somebody opts out?

Does an opt-in have to mention WhatsApp by name?

No, and this is the single most commonly misreported fact in this subject area. A large share of the advice written about WhatsApp opt-in treats a WhatsApp-specific checkbox as a compliance requirement - "make sure your customers opt in to WhatsApp messages specifically" - when Meta's own documentation states the opposite: general opt-in is acceptable (Meta - Getting Opt-In).

The practical effect matters for anyone who already runs a WhatsApp Business API integration alongside email or SMS. If a business already has a general "receive updates from us" opt-in on its website, checkout flow or signup form, it does not need to run a second campaign asking the same customers to re-consent specifically to WhatsApp, provided that original wording already did the two things the next section describes and the jurisdiction's law does not require more.

What it does need is for that original wording to have named the business. A checkbox that says only "I agree to receive updates" with no company name attached to it is a weaker opt-in than one that says "I agree to receive updates from Example Traders" - not because WhatsApp needs naming, but because the business does.

What two things must every opt-in wording contain?

Meta states this as two separate, specific sentences rather than one general instruction, and both survive on their own regardless of channel or local law. The first: businesses "must clearly state that a person is opting in to receive communication from the business." The second: businesses "must clearly state the business's name that a person is opting in to receive messages from" (Meta - Getting Opt-In).

Read together, an opt-in fails if it is missing either half. "Subscribe to our newsletter" states that someone is agreeing to communication, but not from whom, if the surrounding page never names the business. A form footer reading "© Example Traders 2026" beside an unrelated checkbox states the business's name, but not that ticking the box means agreeing to receive messages. Both need to appear, in the same flow, close enough together that a reasonable reader connects them.

Note that the third row of that table is not optional decoration - it is the condition attached to the other two in Meta's own wording, and it is covered on its own later in this piece.

Checked against Meta's documentation on 4 September 2026.

What does a compliant opt-in look like on a website form?

Meta's documentation lists specific methods it recognises as valid ways to collect this permission: "SMS," "Website," "By phone (using an interactive voice response (IVR) flow)," and "In person or on paper (customers can sign a physical document to opt in)" (Meta - Getting Opt-In). A website form is one recognised method among several, not the only one, which matters for the offline collection question later in this piece.

On a website, the two requirements from the previous section translate into ordinary form copy rather than anything technical. A checkout page might read: "Tick here to receive order updates and occasional offers from Example Traders on WhatsApp, SMS or email. You can opt out at any time." That single sentence states what is being agreed to, names the business, and - because it names the channels - removes any ambiguity about whether WhatsApp is included, even though Meta does not require the sentence to say "WhatsApp" at all.

What breaks this in practice is usually brevity, not bad intent. A checkbox squeezed under a payment form often ends up reading just "I agree to marketing," inherited from an email-only signup built years before WhatsApp sending existed. It is short because nobody expected it to be read this closely, not because anyone decided to omit the business's name on purpose.

Separately from the opt-in wording itself, businesses sending template messages should note that Meta categorises the templates as marketing or utility, independent of what the opt-in said - covered in this site's piece on a template recategorised from utility to marketing. Getting the opt-in right does not settle how a given message is categorised once it is sent.

Can you message a list collected before you had WhatsApp?

Meta's documentation does not treat the timing of collection as a separate category, and it does not say anywhere that an opt-in becomes invalid simply because it predates a business's use of WhatsApp. Nothing in the two-part rule in the earlier sections turns on when the number was collected - it turns on what the wording said and who it named.

That means a general marketing opt-in a business collected in 2019, for a newsletter or an SMS programme, can in principle still cover WhatsApp messages sent in 2026, provided the original wording already satisfied the two conditions above and provided local law does not additionally require the person to be told the channel is changing. This is an inference from the shape of Meta's rule, not a sentence Meta's documentation states outright about legacy lists specifically - worth being precise about, because it is exactly the kind of claim that gets overstated into "any list you already own is fair game."

It is not that. The conditional in Meta's own sentence - "as long as businesses comply with all local laws" - does not go away because the list is old. An opt-in collected honestly five years ago for a different purpose, or worded so broadly it never really told anyone what they were agreeing to, does not improve by virtue of age. If anything, older opt-ins are the ones worth checking first, because the wording is more likely to predate anyone thinking carefully about what it needed to say.

Where does local law override Meta's minimum?

Meta's own documentation is explicit that its rule is a floor, not a ceiling: opt-in "can be general and not specifically for WhatsApp, as long as businesses comply with all local laws," and separately, that it is "up to businesses to determine the method of opt-in, that they have obtained opt-in in a manner that complies with laws applicable to their communications, and that they have otherwise provided notices and obtained permissions that are required under applicable law" (Meta - Getting Opt-In).

That sentence puts the actual legal work back onto the business, deliberately, and Meta's documentation does not attempt to enumerate what any specific country's law requires - it could not, across every market it operates in. What it does say is where the line sits: Meta defines the wording an opt-in must contain; local law decides who counts as capable of giving it, how long a record of it must be kept, whether it can be bundled with other consents, and whether a business messaging a customer in one country needs anything beyond what satisfies Meta's own two conditions.

A business selling into India, for instance, is also inside the country's telecom regulations governing commercial messaging - covered separately in this site's piece on DLT registration for the WhatsApp Business API, which is an India-specific registration requirement that sits alongside Meta's opt-in rule rather than replacing it. Neither this page nor Meta's documentation is a substitute for checking what a given market actually requires; the honest position is that Meta tells you the platform's minimum and stops there.

Checked against Meta's documentation on 4 September 2026.

How do you import a customer list without losing rows?

Most opt-in wording is decided before anyone opens a spreadsheet; most of the actual failures happen after, at the point a list is imported into whatever sends the messages. A CSV import has to survive four checks before the rows in it are trustworthy: the file's text encoding, a genuine single header row, duplicate phone numbers, and one malformed row not being allowed to take the rest of the file down with it.

Phone numbers deserve their own line of scrutiny beyond formatting. Two rows with the same number, spelled differently - one with a country code, one without, one with a stray space - do not look like duplicates to software matching strings exactly, and they import as two separate contacts who both receive the same broadcast. Numbers need to be normalised to one consistent format before the file reaches the importer, not after.

A properly built importer separates "this file has a problem" from "this row has a problem." A single malformed row - a phone number with letters in it, a name field containing a stray character the destination column can't store - should produce one line telling you which row and why, and every other row in the file should still land. An importer that aborts the entire batch on the first bad row turns one bad line into hundreds of lost contacts, and that failure mode is common enough to deserve its own section next. A contacts screen built around this - source, status and tag columns alongside the phone number, listed among this site's product features - is what makes a large import auditable after the fact rather than a single opaque upload.

Why do spreadsheets from Excel break contact imports?

The single most common reason a contact CSV fails to import cleanly has nothing to do with opt-in wording and everything to do with character encoding, and it is worth naming precisely because the error message it produces looks unrelated to the actual cause. A file saved by Excel using its default "CSV" option is typically written in Windows-1252, not UTF-8 - and a database column declared to store UTF-8 text (utf8mb4, in most modern setups) refuses certain byte sequences that Windows-1252 produces but UTF-8 does not.

The byte that causes this most often is 0xA0, Windows-1252's non-breaking space - the character Word and Excel insert automatically in places a normal space would look identical on screen but behaves differently underneath. A name field containing one arrives looking completely ordinary and fails on insert with an error naming the column and the offending byte, which reads as a database problem rather than the spreadsheet-export problem it actually is.

The fix has two parts, and only doing one of them is a partial fix. Incoming text needs to be converted from Windows-1252 to UTF-8 on the way in - every one of the 256 possible byte values in Windows-1252 maps to a valid character, so this conversion cannot itself fail, unlike guessing at an unknown encoding. And a bad row still needs to fail on its own, as covered in the previous section, rather than taking a whole chunked insert down with it - a file importing 500 rows at a time that hits one bad row at row 496 should not lose the 495 good rows ahead of it along with it.

What should you store so an opt-in can be proved later?

An opt-in that cannot be reconstructed later is functionally identical to no opt-in at all, from the point of view of anyone who later asks how a number ended up on a list. Four fields cover most of what is needed: the exact wording the person saw or heard, which method collected it (website, SMS, phone/IVR, or in person on paper), the date, and where in the business the record originated.

The wording matters more than businesses tend to assume, because opt-in language changes over time - a checkbox rewritten last year to be clearer does not retroactively fix what an older contact actually agreed to. Storing a snapshot of the wording alongside the contact, rather than trusting that "the current form" describes what everyone on the list saw, is what makes the record defensible rather than just plausible.

This is also where Meta's offline methods stop being a footnote. A signed paper form or a logged IVR call is exactly as valid an opt-in as a website checkbox under Meta's own list of methods, but only the paper trail proves it happened - a business that collected consent correctly in a shop and then never digitised the form has an opt-in it cannot point to. Contacts with a defined source field - shop, website, referral, imported list - make this traceable at scale rather than something reconstructed one contact at a time when a question arises, and visible to every agent working from the same shared team inbox rather than sitting in a spreadsheet only one person can find.

What happens when somebody opts out?

Meta's own guidance treats opt-out as a mirror obligation to opt-in: businesses must "provide clear instructions for how people can opt out of receiving specific categories of messages or calls, and honor these requests" (Meta - WhatsApp Business Policy). On WhatsApp specifically, the mechanism is usually a plain-text reply - STOP, or a local-language equivalent - that a business's messaging system has to recognise and act on before anything else touches that message.

Recognising the word is not the same as acting on it everywhere the person could still be reached. An opt-out has to update whatever field decides whether a contact is eligible for the next broadcast, and it has to be checked again at the moment a campaign actually sends, not only at the moment it launches - someone who opts out between scheduling and delivery still has to be skipped. A system that checks consent once at launch and freezes the recipient list will otherwise message someone who has, by that point, explicitly said no. This is also the mechanism that keeps a business's numbers out of the territory covered separately in this site's piece on what gets a WhatsApp account restricted - complaint volume from people who opted out and kept getting messaged is one of the more direct routes there, and it interacts with whatever broadcast limits a number is already operating under.

Whether that same opt-out has to be honoured on other channels - email, SMS - is not something WhatsApp's own policy reaches, because it governs WhatsApp messaging specifically. That question is answered by what the original opt-in actually covered and, again, by local law, not by anything in Meta's documentation.

Checked against Meta's documentation on 4 September 2026.

Every Meta quotation on this page was read from Meta's own documentation on 4 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.