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.

Advanced

4 min read

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.

Compliance, consent, and choosing how to integrate at all

Advanced

4 min read

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.

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

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.

Compliance, consent, and choosing how to integrate at all

What WhatsApp's own platform rules enforce, functioning as compliance requirements

Data protection law, in shape rather than specifics

Direct Cloud API vs. a Business Solution Provider (BSP) — the real trade-off

Further reading

Compliance, consent, and choosing how to integrate at all

What WhatsApp's own platform rules enforce, functioning as compliance requirements

Data protection law, in shape rather than specifics

Direct Cloud API vs. a Business Solution Provider (BSP) — the real trade-off

Further reading