GDPR-compliant WhatsApp opt-in: website, button and double opt-in in chat

In our previous article we described why the first step at Grovia Digital runs through WhatsApp instead of a contact form. The most frequent follow-up question was always the same: is that even compliant with data protection law?

The short answer is yes, but not automatically. WhatsApp in sales can be done cleanly, but it depends entirely on how consent is collected and documented. That is what this article is about: which routes exist to obtain an opt-in, how a double opt-in works directly inside the chat, and what else it takes for the channel to survive an audit. Note that the rules below are the German and EU framework, which is where we operate.

Which laws apply to WhatsApp in sales?

Many companies only think of the GDPR when it comes to WhatsApp. In fact two sets of rules are relevant, and they ask different questions.

The GDPR governs whether you may process personal data at all. For promotional messenger communication that is usually consent under Article 6(1)(a). Article 7 additionally requires that you can demonstrate that consent.

German competition law, the UWG, governs whether you may approach someone through this channel in the first place. Messenger messages count as electronic mail there and therefore fall under the same requirements as email advertising under Section 7(2). Important for B2B sales: there is no general exemption for business customers in Germany.

In practice that means: without prior, explicit and demonstrable consent you may not send promotional WhatsApp messages to anyone. Full stop.

Why the WhatsApp Business app is not enough

Before opt-ins even come up, the foundation has to be right. The free WhatsApp Business app is critical for professional use because it syncs the device address book with Meta. That transfers contact details of people who know nothing about it and never agreed to it.

The defensible option is the WhatsApp Business Platform, in other words the official API. It allows a data processing agreement under Article 28 GDPR and does not sync contacts. Access runs either through a Meta-authorised Business Solution Provider such as Chatarmin, 360dialog or Superchat, or directly via the Cloud API. The direct route saves an intermediary and one more processing agreement, but asks for a bit more work of your own during setup and operation. We take the direct route. If you do pick a provider, look for European hosting and a clean processing agreement with them.

Route 1: how do you collect consent on your website?

The classic route. The prospect leaves their mobile number on your website and actively agrees to being contacted via WhatsApp.

For that consent to be valid it has to meet several criteria. It must be given actively, a pre-ticked checkbox is not enough. It must be voluntary, so the user must not be disadvantaged for declining. And it must state specifically what the agreement covers.

A consent text should therefore name who the controller is, what kind of messages the user will receive, that processing runs through WhatsApp and therefore Meta, that consent can be withdrawn at any time, and it should link to the privacy policy. One possible wording next to the phone number field:

Yes, I would like Example Ltd to contact me via WhatsApp to deliver my assessment and answer open questions. My number will be transmitted to our service provider and to WhatsApp (Meta) for this purpose. I can withdraw this consent at any time, for example by sending STOP. Further information is in our privacy policy.

Keep this text separate from other agreements. A combined checkbox for terms, newsletter and WhatsApp at once is invalid.

Route 2: what does the WhatsApp button cover, and what does it not?

This is where it gets more interesting, because the sequence is different. With a click-to-chat button or a QR code, the user messages you first. So they pick the channel themselves.

That opens what is called the service window. If a user messages you first, you may reply freely for 24 hours, without a pre-approved message template and without a separate opt-in. For a consultation that is often already enough.

Two points are regularly overlooked. First, the incoming message is not marketing consent. It covers the running conversation, but not a message two weeks later with an offer. That needs explicit agreement.

Second, you still need a privacy notice. Even when the user takes the first step, you are processing their data from that second onwards and must inform them under Article 13 GDPR. That belongs in the first automated reply.

How does double opt-in work inside the chat?

This is exactly where double opt-in comes in, and in WhatsApp it works more elegantly than over email.

With an email newsletter, the confirmation link mainly proves that whoever signed up actually has access to that inbox. On WhatsApp that proof already exists, because the message demonstrably comes from the device of the number owner. What is missing is documented agreement to the content.

Step 1, the opening message. The bot names the company, explains in one sentence what is about to happen, points out that the conversation is AI-supported, and links the privacy policy.

Step 2, the confirmation question. At the right point in the flow an explicit question appears with two reply buttons, for example: "May we get back in touch later if something changes in the findings?" With the options "Yes, please" and "No, thanks". What matters is what the question refers to: the later contact, not the service that is currently running.

Step 3, the confirmation. On "Yes" the timestamp is stored and the contact may be approached later. On "No" nothing further happens and no more messages follow.

Where in the flow does the consent question belong?

This is not a detail, it is the point where most implementations fall over. If the question sits as a gate in front of the actual service, that service appears to depend on the agreement. Under Article 7(4) GDPR, the prohibition on bundling, the consent is then no longer unambiguously freely given, and being freely given is precisely its precondition.

It is much cleaner to deliver first and ask afterwards. Someone who already has the assessment in hand and then answers "no" loses nothing. A side effect: the consent you collect this way is worth more in substance too, because it comes from someone who has already seen your work.

It also matters that the confirmation question itself stays neutral and contains no advertising. That requirement is familiar from German case law on confirmation emails in double opt-in, and it transfers one to one.

The practical advantage: what is a media break with a noticeable drop-off risk over email costs exactly one tap in WhatsApp.

What do you have to document?

Consent you cannot prove is worthless in a dispute. So store at least the following for every opt-in:

• the phone number and, where available, the linked contact record
• date and time it was given
• the channel it was given through, so website form, button or QR code
• the exact wording of the consent text at the time it was given
• the version number of the flow or the form
• for website opt-ins additionally the IP address
• date and time of a later withdrawal

Versioning is the point most often forgotten. If you change your flow text in November, you still have to be able to prove the following year which text a contact saw in March. A screenshot or export per version solves that.

Keep the records at least as long as you rely on the consent. After a withdrawal, three years in line with the standard limitation period is common practice.

How easy does opting out have to be?

Exactly as easy as opting in. In practice that means a keyword like STOP that is recognised automatically and sets the contact to inactive immediately. It works in both directions: it ends the running conversation and, where one was given, withdraws the consent for later messages. Point to it actively inside the flow instead of hiding it.

You also need a suppression list. Anyone who has objected must not be contacted again by accident during a later data import.

What does the EU AI Act change since August 2026?

Since 2 August 2026 the transparency obligations in Article 50 of the EU AI Act apply. Anyone running an AI-supported system in customer contact must make it recognisable at the start of the interaction that the user is not writing to a human. Fines go up to 15 million euros or three percent of global annual turnover.

For systems that were already on the market before 2 August 2026, the AI Omnibus package from May 2026 provides a transition period until 2 December 2026. That period mainly concerns machine-readable marking of AI-generated content, though. Relying on it for a chatbot is a bet you do not need to take: implementation costs one sentence in the opening message, for example "I am an AI assistant from Grovia Digital. A colleague can take over at any time."

In our experience that notice costs no conversion. It does the opposite, because people know where they stand.

The rest of the checklist

Beyond the opt-in, a clean setup includes:

• a data processing agreement with Meta for the Business Platform and, if a BSP is used, one with them as well
• a WhatsApp section in the privacy policy naming purpose, legal basis, recipients and retention
• the entry in the record of processing activities
• a deletion concept with defined retention periods for chat histories
• a review of the third-country transfer to the US, as Meta falls under the EU-US Data Privacy Framework
• an internal rule on which employees have access to the chats

How we run it

Both Grovia workflows, the short AI assessment and the check of visibility inside AI models, start identically: opening message with sender, a note about the AI assistant and a link to the privacy policy, then the qualification questions. For that part we do not need consent, because the prospect writes to us on their own initiative and requests an assessment. That is a pre-contractual measure at their request.

Two things have to be kept apart here. The processing for the assessment itself rests on Article 6(1)(b) and (f). Consent under (a) is only needed for the second case, namely when we want to get back in touch later without a new trigger. For that case we ask for it explicitly. The existing-customer exemption in Section 7(3) of German competition law does not help here, by the way: it presupposes an actual sale, and a lead has bought nothing.

So the consent comes afterwards. Once the assessment has been delivered, we ask in a separate message with two buttons whether we may get back in touch later, for example if something changes in the findings we measured. Saying "no" costs nothing at that point, because the assessment has long since been delivered. That is exactly why the question sits there and not at the start.

Every answer is logged with timestamp, channel and the version of the text the prospect saw. When sales picks up the lead, they see not only the answers but also whether they are allowed to contact them later. That is not a by-product, it is the precondition for the channel being scalable at all.

The additional effort is one message at the end of the flow. Measured against what a missing record costs in a dispute, that is a good investment.

Conclusion

WhatsApp in sales rarely fails because of the GDPR, it almost always fails because of missing documentation. If you collect consent cleanly, have it confirmed inside the chat and log both in an audit-proof way, you have a channel that holds up legally and converts far better than any form.