WhatsApp data privacy for bot builders: what you are now holding

A form collects the fields you asked for. A conversation collects whatever somebody chose to say, which on a personal messaging channel is regularly more than you intended to hold — a health detail in a booking request, a photograph of a document, a family circumstance explaining a cancellation.

That difference is the whole subject. The obligations follow from what you are holding rather than from what you designed to collect, and a bot that stores full transcripts is holding a category of data most teams have not assessed.

What we'll cover

• Conversations collect more than forms
• What ends up in your systems
• End-to-end encryption and what it does not mean
• Building it with CodeWords
• Consent, separately from opt-in
• Retention, which needs a decision
• Requests you have to answer
• Processors and where data goes
• Telling customers what is happening
• Making it survive
• Limits worth knowing about
• What to do first
• Frequently asked questions

Conversations collect more than forms

People volunteer context because the channel feels personal and conversational.

Health information appears in appointment and cancellation messages routinely, across sectors that do not consider themselves healthcare.

Financial circumstances appear in payment and refund conversations.

Photographs arrive of documents, homes, injuries, vehicles and occasionally people who are not the customer.

Other people are mentioned, whose data you now hold without any relationship with them.

None of this was designed, which is precisely why it needs assessing rather than assuming your form-based analysis covers it.

What ends up in your systems

The phone number, which is a strong identifier and in several regimes personal data on its own.

The profile name, as the customer set it.

Full message content, if you store transcripts, including everything above.

Media files, fetched and stored by you.

Derived data — extracted intents, classifications, summaries — which are also personal data about that person.

Metadata: timing, frequency, read status, which reveals patterns about somebody's life.

End-to-end encryption and what it does not mean

Messages are encrypted in transit between the parties, which is a genuine property of the consumer product.

You are one of the parties. Once a message reaches your business, it is decrypted and you hold it.

Encryption protects it from interception, not from your own storage, logging or processing.

Your provider sees it too where you use a Business Solution Provider, which is a processing relationship needing an agreement.

Do not tell customers their messages are private from you, which is a claim some businesses make and it is not accurate.

Your obligations are the same as for any other channel carrying the same content.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what is extracted, what is stored, and what is discarded.
3. Authorize the connection to your WhatsApp Business Platform account and the systems that hold the records.
4. Describe the exceptions: a message containing something you should not retain, a deletion request, a conversation needing a person.
5. Run it and read what actually landed in storage before processing real volume.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Consent, separately from opt-in

Opt-in to be messaged and consent to process data are different things, and are frequently conflated.

Your lawful basis for processing may not be consent at all — a contract or a legitimate interest may apply — and knowing which one matters when somebody objects.

Tell people what you do with it, in a privacy notice that actually covers the conversational channel rather than only your website.

Automated decisions that significantly affect somebody carry additional obligations in several regimes, including a route to human review.

Special category data — health, and others — needs a stronger basis than ordinary personal data, and it arrives on this channel whether you asked for it or not.

Get the position confirmed for your jurisdiction rather than reasoning from a blog post, including this one.

Retention, which needs a decision

Indefinite is a decision, taken by default, and it is the one most likely to be wrong.

Decide per category: transcripts, extracted fields, media, derived data.

Transcripts age badly. Their usefulness declines quickly and their risk does not.

Extract and discard where you only needed a booking date from a conversation.

Delete media once the purpose is served, since it is the highest-risk content you hold.

Automate the deletion, because a policy that depends on somebody remembering is not a retention policy.

Requests you have to answer

Access: somebody asking what you hold about them, which requires you to find it across every system.

Deletion: which must reach transcripts, media, derived records and backups within your stated approach.

Correction, which is straightforward for fields and awkward for a transcript of something they said.

Objection, which may end processing you were relying on.

Find by phone number, since that is the identifier a requester will supply and your systems may key on something else.

Test the process before you receive one, because discovering mid-request that transcripts are unsearchable is expensive.

Processors and where data goes

Your Business Solution Provider processes your messages, which needs an agreement and appears in your records.

Any model provider you send message content to is another processor, and what they retain matters.

Storage and processing locations matter in several regimes, particularly for transfers out of a region.

Sub-processors change, and knowing when is part of the arrangement rather than a courtesy.

Your privacy notice must reflect this, which means updating it when the stack changes.

Minimise what leaves. The least complicated processing relationship is the one you do not have.

Telling customers what is happening

Most of the discomfort customers feel about an automated messaging channel comes from not knowing what they are talking to or where it goes.

Say it is automated, early and plainly, which is required in some jurisdictions and reduces complaints everywhere.

Offer a person at any point, visibly, rather than as something to be discovered by frustration.

Explain what you keep in the privacy notice the channel actually links to, rather than one written for a website.

Do not ask for more than you need in a conversation, since people answer questions in a chat that they would abandon a form over.

Warn before sensitive territory. If a conversation is heading towards payment details or health information, that is the moment to move it somewhere appropriate.

Never ask for card details in chat, which is both a data problem and a pattern that trains customers to respond to exactly the message a fraudster would send.

Making it survive

Store the minimum that makes the automation work, and discard the rest on a schedule.

Key records on the phone number so a request can be answered.

Make deletion actually delete, including from search indexes, logs and analytics.

Restrict access to transcripts more tightly than to extracted fields, since the transcript holds everything.

Report the outcome: what is retained by category, what was deleted on schedule, and any request handled.

Limits worth knowing about

Rules differ by jurisdiction and your customers may be in several.

A provider's compliance is not yours, and their certifications do not discharge your obligations.

Backups complicate deletion, and your approach needs to be stated rather than assumed.

Special category data will arrive whether or not you handle it, which is a reason to have decided in advance.

This is not legal advice, and the position for your business needs confirming with somebody qualified for your markets.

What to do first

Read a sample of fifty real conversations and mark what people actually volunteered. Most teams find health details, financial circumstances, third-party information and photographs they never intended to collect, and that sample is both the assessment and the argument for deciding retention deliberately.

Two habits make the difference. Extract what you need and discard the transcript where the conversation was a means to a booking or an order, since the transcript's usefulness declines quickly and its risk does not. And test a deletion request before you receive one, because finding out mid-request that transcripts are unsearchable by phone number is an expensive way to learn it.

Frequently asked questions

Why is a conversational channel different from a form?

A form collects the fields you asked for; a conversation collects whatever somebody chose to say. Health details, financial circumstances, third-party information and photographs arrive routinely without being designed for.

Does end-to-end encryption protect customer messages from me?

No. You are one of the parties, so once a message reaches your business it is decrypted and you hold it. Encryption protects against interception, not against your own storage and processing — and telling customers otherwise is inaccurate.

Is opt-in the same as consent to process data?

No, and conflating them is common. Your lawful basis for processing may be a contract or a legitimate interest rather than consent, and knowing which applies matters when somebody objects.

What should retention look like?

Decided per category — transcripts, extracted fields, media, derived data — and automated. Indefinite retention is a decision taken by default, and transcripts in particular lose usefulness quickly while retaining their risk.

What requests do I need to be able to answer?

Access, deletion, correction and objection — found by phone number, since that is the identifier a requester supplies. Deletion must reach transcripts, media, derived records and backups consistently with your stated approach.

Who else processes this data?

Your Business Solution Provider, any model provider you send message content to, and their sub-processors. Each needs an agreement, and your privacy notice should reflect the actual stack rather than an earlier version of it.

What about special category data?

It arrives on this channel whether you asked for it or not — a health detail in a cancellation message is the common case — and it needs a stronger basis than ordinary personal data. Decide in advance rather than on discovery.

Where should I start?

Read fifty real conversations and mark what was volunteered. It is the assessment and the argument at the same time, and it is more convincing than any policy document.

Should I store full transcripts?

Only where you need them. Extract what the automation requires — a booking date, an order reference — and discard the rest on a schedule, since a transcript holds everything the customer said rather than the part you needed.

Who can see the transcripts internally?

Fewer people than can see the extracted fields, which is the access split most implementations do not make. The transcript contains whatever was volunteered; the fields contain what you designed to collect.

Should customers be told they are talking to a bot?

Yes — required in some jurisdictions and sensible everywhere, with a visible route to a person rather than one discovered through frustration.

Can I collect payment details over WhatsApp?

No. Beyond the data handling problem, asking for card details in chat trains customers to respond to exactly the message a fraudster would send them.

Related reading

• WhatsApp automation mistakes that get numbers flagged
• WhatsApp webhooks explained
• Workflow automation for education