Architecting Tenant-Specific WhatsApp Reminders in a Multi‑Tenant SaaS

Email would have been straightforward. Every tenant gets a "from" address on a shared domain, or their own domain if they want it, and the sending infrastructure barely changes between tenants. WhatsApp doesn't work that way. A WhatsApp number is tied to an account, verification status, and a specific relationship with Meta's Business Platform. That difference forced two architectural questions before any code got written: who owns the sending number, and which integration path handles the actual message delivery.

The Core Questions

Who owns the sender number: the platform, or each tenant?

If every tenant's reminders go out from one platform-wide number, the message shows up to the end customer carrying the platform's identity, not the vendor's. A hair salon or a repair shop using the platform loses the direct, personal-looking contact that WhatsApp business messaging usually implies. Customers see "SaaS Platform" instead of the business they actually booked with.

If each tenant sends from their own number, they look like themselves - which matters a lot for trust in a WhatsApp-first market. But it means every tenant has to go through WhatsApp Business verification individually, which is not instant, not guaranteed, and adds friction to onboarding. A platform with hundreds of small tenants can't reasonably expect all of them to clear that process smoothly, especially the ones with no prior business documentation.

Neither option is a clean win. A shared number is easier to operate but weaker on tenant branding. Per-tenant numbers are stronger on branding but push verification overhead onto every single tenant.

Third-party provider or WhatsApp Cloud API directly?

The second question was about the delivery layer itself. Third-party WhatsApp Business Solution Providers (BSPs) handle a lot of the operational complexity - number provisioning, template management, webhook infrastructure - but they charge on top of what WhatsApp itself charges per conversation. At low volume that markup is easy to absorb. Projected out across a growing multi-tenant base, it compounds into a real cost difference.

Going direct through the WhatsApp Cloud API removes that markup, but it also removes the part of the work the third party was doing for you. Number management, message templates, rate limits, and webhook handling all become the platform's responsibility instead of something abstracted away.

Weighing the Trade-offs

Running the numbers on projected message volume as the tenant base grows made the cost gap between direct and third-party too large to ignore. The third-party markup scales linearly with usage, so the more successful the platform gets, the more expensive that decision becomes. Direct integration costs more engineering time up front - building out template management, delivery status tracking, and number provisioning in-house, but that cost doesn't scale with volume the same way a per-message markup does.

That's the deciding factor: a cost structure that grows with the platform versus one that stays roughly fixed. Direct integration through the Cloud API was the better fit for a platform meant to scale.

Decision

The platform is moving forward with the WhatsApp Cloud API directly rather than a third-party BSP.

On the sender-number question, the decision is per-tenant numbers. Reminders need to come from the vendor's own WhatsApp identity, not the platform's. A customer getting a reminder from the business they actually booked with reads as legitimate. A reminder sent from a shared platform number reads as a notification from a system they don't recognize, which works against the point of the message.

This puts the verification burden on onboarding. Every tenant will need to complete WhatsApp Business verification before their reminders can go live, and that step has to be designed as part of the onboarding flow rather than bolted on afterward - clear guidance on what documentation is needed, visibility into verification status, and a fallback (email, in the interim) so a tenant isn't blocked from using the platform while their number is still pending approval.

Where Things Stand

Setting up a WhatsApp Business Platform account for managing multiple numbers under one account is in progress. Meta's requirements for this are not light - business verification, display name review, and a set of prerequisites before they'll approve an account for multi-number management. It's a slower process than provisioning email sending infrastructure, but it's moving.

Takeaways

• WhatsApp messaging infrastructure doesn't generalize from email patterns. Sender identity is tied to account-level verification, not just a header field, so multi-tenant number strategy has to be decided before onboarding flows are built, not after.
• Cost comparisons between third-party providers and direct API integration should be projected against expected scale, not current volume. A markup that looks negligible early on can become the dominant cost line as usage grows.
• A branding requirement (looking like the vendor, not the platform) can settle an architecture question that cost trade-offs alone don't resolve. Once professional identity was treated as non-negotiable, the number-ownership decision followed directly, even though it pushes more setup work onto onboarding.
• Any decision that adds friction to onboarding (verification, documentation, approval delays) needs a fallback path designed alongside it, not after. Otherwise tenants get blocked on something outside their control before they've had a chance to use the product.