Summarise this article with:
On this page
Most Indian businesses on the WhatsApp Business API collected their opt-ins before anyone was thinking seriously about the Digital Personal Data Protection Act. A checkbox buried in a signup form, a bulk import of "existing customers," a verbal yes at a store counter — all of it now sits in a grey zone that two separate rulebooks care about: Meta's opt-in policy, which decides whether your account keeps its messaging tier and quality rating, and the DPDP Act, which decides whether your consent would survive scrutiny from the Data Protection Board.
The good news is that these two rulebooks mostly point in the same direction. A consent flow that satisfies the DPDP Act's requirements — free, specific, informed, unconditional, unambiguous, given through a clear affirmative action — will almost always satisfy Meta's policy too. The reverse is not true: Meta's policy is looser in places, and a flow built only to Meta's minimum can still fall short of the Act. So the practical move is to build to the stricter standard once, and document it well enough that you can prove it later.
What "valid consent" actually means under both rulebooks
The DPDP Act (Section 6) requires consent that is free, specific, informed, unconditional, and unambiguous, signalled by a clear affirmative action. Each word does real work:
- Free — the customer can decline WhatsApp messages and still buy from you. Making WhatsApp opt-in a condition of checkout fails this test.
- Specific — consent to "communications" is not consent to WhatsApp marketing. Name the channel and the purpose.
- Informed — the person should know who is collecting the data, what will be sent, and how to withdraw. The Act also expects notices in plain language, with the DPDP Rules pointing towards availability in Indian languages listed in the Eighth Schedule.
- Unconditional and unambiguous — no inference from silence, no pre-ticked boxes, no "by continuing you agree" footers doing the heavy lifting.
Meta's opt-in policy for the WhatsApp Business API asks for less detail but the same substance: businesses must obtain opt-in before sending proactive (template) messages, the opt-in must clearly state the person is opting into WhatsApp messages from your business, and it must be obtained through a method the person actively completes. Meta doesn't audit your consent records the way a regulator might — instead it enforces indirectly, through block rates. When users who never meaningfully opted in start hitting "Block," your quality rating drops, your messaging tier gets cut, and in persistent cases the number gets restricted. We see this across accounts: the businesses fighting quality-rating problems are almost always the ones with the weakest opt-in hygiene.
One distinction worth internalising: service conversations don't need marketing consent. When a customer messages you first, you have a 24-hour window to respond freely — that's session messaging, and replying to an inbound query is not the kind of processing that needs a separate marketing opt-in. The consent machinery in this post is about business-initiated messages: order updates, marketing broadcasts, payment reminders sent via approved templates.
Collection surfaces: where and how to capture opt-in
Different entry points need different mechanics. Here are the four we see most in Indian deployments, with copy you can adapt.
Checkout and signup forms
The most common surface, and the most commonly botched. The failure pattern is a single checkbox covering "SMS, email, WhatsApp and calls" — that's bundled consent, and it fails the DPDP Act's specificity requirement.
Do this instead — an unticked checkbox, separate from terms acceptance:
<label>
<input type="checkbox" name="wa_optin_transactional" />
Send my order updates and delivery alerts on WhatsApp
to +91-XXXXXXXXXX
</label>
<label>
<input type="checkbox" name="wa_optin_marketing" />
I'd also like offers and product updates on WhatsApp
(typically 2–4 messages a month). Reply STOP anytime.
</label>
Splitting transactional and marketing consent costs you a few percentage points of marketing opt-in rate — in our experience the marketing box gets ticked by somewhere between 30% and 60% of checkout users, depending on category and copy — but it buys you two things: a defensible consent record, and a marketing list of people who actually want the messages, which is what keeps read rates in the healthy 70–85% band rather than the 40% you get from a coerced list.
Website chat widget
A click-to-chat widget starts a user-initiated conversation, which handles the session-messaging side automatically. The opt-in question is what happens after the 24-hour window. Two workable patterns:
- In-conversation opt-in — after resolving the query, send an interactive message: "Want order updates and occasional offers on WhatsApp? Tap Yes, keep me posted or No thanks." A button tap is a clear affirmative action, and you get a message ID as evidence.
- Pre-chat disclosure — text next to the widget button: "Chatting with us on WhatsApp lets us reply to your query. We'll only send you other updates if you separately opt in."
If you're adding a widget, our /tools/whatsapp-widget-generator produces the embed code; the disclosure copy is yours to place alongside it.
QR codes (packaging, in-store, print)
QR codes that open a WhatsApp chat with a pre-filled message are increasingly common on Indian retail packaging and restaurant tables. The pre-filled message is your friend here — make it self-documenting:
Pre-filled text: "Hi! I'd like to register my purchase and receive warranty updates on WhatsApp."
When the user hits send, the message itself records what they asked for. A kirana-adjacent example: a Pune appliance brand we work with prints a QR on the warranty card; the pre-filled message names warranty registration specifically, and a follow-up interactive message asks separately about promotional content. Registration completion sits around 20–35% of scans, but every registration is a clean, scoped opt-in.
The trap: a QR that says only "Scan to chat" and then lands the user on a broadcast list. The scan proves interest in a conversation, not consent to marketing. Scope stays with what the user could reasonably see before scanning.
IVR and call-centre capture
For businesses with heavy phone volume — clinics, financial services back-offices, logistics — IVR opt-in works if the prompt is specific and the keypress is logged:
"To receive your appointment confirmations and reports link on WhatsApp on this number, press 1. To continue without WhatsApp updates, press 2."
Store the DTMF response with the call recording reference. For agent-assisted calls, a verbal yes is weaker evidence; the stronger pattern is agent-triggered confirmation — the agent sends a template ("You asked us to send updates on WhatsApp — reply YES to confirm") and the customer's reply becomes the recorded affirmative action. It adds a step, but it converts a claim into a log entry.
Record-keeping: what to store for every opt-in
Under the DPDP Act, the burden of proving consent sits with the data fiduciary — you. Under Meta policy, you may be asked to demonstrate opt-in if your account is flagged. Either way, an opt-in you can't evidence is barely an opt-in. Minimum fields per record:
| Field | What it captures | Example |
|---|---|---|
| Phone number | The consenting identity | +91XXXXXXXXXX |
| Source | The surface and specific placement | checkout_v3, qr_warranty_card, ivr_menu_2 |
| Timestamp | When consent was given (with timezone) | 2026-06-14T11:32:08+05:30 |
| Scope | Which message categories were consented to | transactional, transactional+marketing |
| Consent text version | The exact wording shown, by version ID | optin_copy_v4 |
| Evidence pointer | Form submission ID, message ID, call recording ref | msg_wamid.HBg... |
| Status + status history | Active / withdrawn, with change timestamps | active |
Two of these get skipped constantly and matter most in a dispute. Consent text version: if you can't reproduce what the user actually saw, you can't show the consent was informed. Version your copy like you version code. Scope: without it, every opt-in silently becomes an all-purpose opt-in, which is exactly what purpose limitation forbids.
Keep the records queryable. "Show me every active marketing opt-in collected via the checkout between March and May" should be a filter, not a data-engineering project. If your current stack can't answer that, fix the logging before scaling the sends.
Opt-out handling: the obligation people underweight
The DPDP Act makes withdrawal of consent a right, and requires that withdrawing be as easy as giving consent was. Meta's commerce and messaging policies expect businesses to honour stop requests. Operationally, that means:
- Honour every reasonable stop signal, not just your official keyword. "STOP" is the convention, but "stop sending", "unsubscribe", "band karo", "mujhe message mat bhejo" all express the same intent. Configure keyword matching generously and route ambiguous cases to a human. A user who typed "please stop" and kept receiving broadcasts is a block — and possibly a complaint — waiting to happen.
- Act promptly. The Act doesn't fix a number of hours; operationally, opt-outs should take effect before the next scheduled send, whatever that requires. Suppress at send-time, not just at list-build time, so a campaign queued yesterday doesn't message someone who opted out this morning.
- Scope the opt-out correctly. Someone stopping marketing broadcasts hasn't necessarily refused delivery updates for an order in transit. Offer the distinction ("Reply STOP for offers only, or STOP ALL for everything except messages you request") — but if the user's intent is unclear, suppress the broader scope. When in doubt, send less.
- Log the opt-out with the same rigour as the opt-in. Source, timestamp, scope, evidence pointer. Withdrawal records are consent records.
- Confirm once, then go quiet. A single acknowledgement ("You won't receive further offers from us. Reply START to resume.") is fine. A win-back sequence to someone who just opted out is not.
Every marketing template you submit should carry the opt-out instruction in its footer. It's cheap insurance for quality rating and it demonstrates the "easy withdrawal" standard on every single message. Our /templates library ships marketing templates with the opt-out footer already in place.
Purpose limitation in practice
Purpose limitation is the DPDP principle that data collected for one purpose can't be quietly repurposed for another. On WhatsApp it bites in very concrete ways:
- A number collected for delivery updates cannot be added to the festive-offers broadcast list. Different purpose, different consent.
- A number collected by your support team to resolve a complaint is not fair game for your sales team's outreach cadence.
- A clinic collecting numbers for appointment reminders should not use the same list for health-camp promotions — and in healthcare, keep messaging strictly operational (reminders, reports-ready notifications, payment links) rather than anything resembling medical advice.
The operational implementation is the scope field from your consent record, enforced at send time. Before any broadcast, the audience filter should be scope includes marketing AND status = active — not "everyone in the CRM with a phone number." If your broadcast tool can't filter on consent scope, that's the gap to close first.
Purpose limitation also has a quiet upside: scoped lists perform. A festive campaign to 8,000 genuinely opted-in contacts will typically produce more revenue — and dramatically fewer blocks — than the same campaign to 40,000 scraped or repurposed numbers. Deliverability follows consent quality; Meta's quality-rating system effectively guarantees it.
Your opt-in compliance checklist
| # | Check | Status |
|---|---|---|
| 1 | Opt-in requires an affirmative action (no pre-ticked boxes, no bundled consent) | ☐ |
| 2 | Consent copy names WhatsApp specifically and states message types and rough frequency | ☐ |
| 3 | Transactional and marketing consent are captured separately | ☐ |
| 4 | Opt-in is not a condition of purchase or service | ☐ |
| 5 | Every opt-in record stores source, timestamp, scope, copy version, and evidence pointer | ☐ |
| 6 | Consent copy is versioned and historical versions are retrievable | ☐ |
| 7 | Legacy/unevidenced contacts have been re-permissioned or excluded from marketing | ☐ |
| 8 | STOP and equivalent phrases (including vernacular) trigger suppression automatically | ☐ |
| 9 | Opt-outs are suppressed at send time, before the next scheduled broadcast | ☐ |
| 10 | Opt-outs are logged with scope and timestamp, and a single confirmation is sent | ☐ |
| 11 | Broadcast audiences are filtered by consent scope, not CRM presence | ☐ |
| 12 | Marketing templates carry an opt-out instruction in the footer | ☐ |
| 13 | Consent records are queryable by source, scope, date range, and status | ☐ |
If you can tick all thirteen, you're built to the stricter of the two standards, and your quality rating will thank you long before a regulator ever asks.
Where InfiQ fits
InfiQ operates on the WhatsApp Business API as a Meta Business Partner, and the platform handles the mechanical parts of this: consent-scoped contact attributes, automatic keyword-based opt-out suppression, send-time exclusion of withdrawn contacts, and exportable consent logs with source and timestamp. The parts it can't do for you — writing honest consent copy, deciding your scopes, re-permissioning a legacy list — are one-time efforts that pay back on every campaign after.
If you want to see how your current flow measures against the checklist, the 7-day free trial is enough time to wire up a widget, run a scoped test broadcast, and inspect the consent logs yourself. Start with the /compliance overview, and use the widget generator if your site doesn't have a compliant entry point yet.
