Compliance, consent, and choosing how to integrate at all
Phone numbers are personal data, and two easily-conflated consent questions carry very different risk. Plus the actual trade-off between going direct to Meta's Cloud API versus routing through a Business Solution Provider.
4 min read
Two consent questions that are not the same thing
- Transactional consent — a customer who gives a phone number for a service (a booking, an order, a signup) has given reasonable implied consent to receive messages about that service. This is the normal, low-risk case every earlier lesson in this domain has assumed.
- Marketing consent — anything promotional needs separate, explicit opt-in. Reusing a phone number collected for a transactional purpose to send an unsolicited "check out our new offer" message is exactly the kind of scope-creep that damages a number's Meta quality rating — and, under most data-protection frameworks, is also the more legally exposed of the two categories.
The practical rule: never let a marketing send reuse a phone number from a transactional context without an explicit, separately tracked "yes, message me about offers" flag. This is easy to build in from the start and genuinely awkward to retrofit once a schema already has phone numbers flowing freely between transactional and marketing use.
What WhatsApp's own platform rules enforce, functioning as compliance requirements
- Opt-out must be honored. If a recipient replies "STOP" (or blocks the number), that must actually be respected — not re-adding them to a future broadcast list. This needs to be tracked in whichever system originates marketing sends, not left as an informal assumption.
- Template content must match its declared category (covered in an earlier lesson) — this is also a trust mechanism, not just an approval gate. A Utility-declared template quietly carrying promotional content later risks the whole number's standing.
- Message content retention is largely the integrating business's own responsibility. Meta itself retains message content only briefly server-side by design — a business's own database is the actual long-term record if conversation history is logged at all (relevant to any AI-assistant-over-WhatsApp feature). Stored conversation logs deserve the same retention/deletion discipline as any other personal data a system holds.
Data protection law, in shape rather than specifics
Personal data protection law varies by jurisdiction, but the shape of what typically applies is consistent enough to plan around:
- Processing personal data (a phone number qualifies) generally needs a lawful basis — for transactional messages, "necessary to perform the requested service" is the natural basis; for marketing, explicit consent is the expected one, reinforcing the same opt-in rule above independent of WhatsApp's own platform policy.
- People generally have a right to know what's held about them and to request deletion — worth considering, concretely, how a "delete my data" request would actually be fulfilled across a system's database and any exported/synced copies, not just the source table.
- This isn't legal advice, and treating it as such would be a mistake — flag genuine compliance edge cases to actual counsel rather than reasoning them out from general platform documentation.
Direct Cloud API vs. a Business Solution Provider (BSP) — the real trade-off
Nothing about this domain requires going direct to Meta. A BSP (a third-party provider reselling and layering tools on top of the same underlying WhatsApp Business Platform) is a legitimate, common alternative:
Arguments for going direct (Meta Cloud API, everything this domain has covered):
- No BSP markup on top of Meta's base per-message rate.
- One account, one integration pattern, full control over templates and webhook handling.
- Once the account setup (Business Portfolio, WABA, permanent token) exists, reusing it for additional projects is close to free.
Arguments for a BSP:
- Many BSPs bundle useful extras the raw Cloud API doesn't provide on its own — automatic SMS fallback when a number isn't WhatsApp-reachable, a built-in shared team inbox for multiple agents handling the same number's conversations, simplified onboarding.
- The Cloud API alone has no concept of "multiple human agents replying to the same inbox" — that's either a BSP feature or something a business has to build itself.
- For a feature like OTP delivery with SMS fallback, a BSP's bundled fallback can be worth the markup, since building equivalent fallback logic against two separate providers directly is real engineering work for a comparatively low-stakes message type.
A reasonable default: go direct for anything where template richness, cost at volume, and full control matter most (rich bilingual notifications, an AI assistant's outbound messages). Consider a BSP when a specific bundled feature (SMS fallback, a shared inbox) would otherwise have to be built from scratch, and that feature matters more than raw cost for the use case at hand. Neither choice is "wrong" — they're suited to different shapes of problem, and a single organization can reasonably run both simultaneously for different use cases rather than forcing one pattern everywhere.
Further reading
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. A customer's phone number, collected during checkout for order updates, is later added to a promotional newsletter broadcast without any additional consent step. What's wrong with this?
2. A recipient replies "STOP" to a marketing broadcast. What is the business expected to do?
3. Who is responsible for retention/deletion policy on logged WhatsApp conversation history, if a business chooses to store it (e.g. for an AI assistant)?
4. A product needs OTP delivery with automatic SMS fallback when a number isn't WhatsApp-reachable. What does this lesson suggest?