The mistake that takes all your clients offline simultaneously
The most dangerous architecture mistake an agency can make: putting multiple clients on the same WhatsApp Business Account (WABA). It looks like it saves admin overhead. It is a time bomb.
Here is what happens when one client violates Meta's messaging policies — sends unsolicited messages, gets spam-reported by enough recipients, or uses an unapproved template for the wrong purpose:
Meta restricts or suspends the WABA. Not just the offending phone number — the entire WhatsApp Business Account. Every phone number under that WABA stops receiving and sending messages simultaneously. If you have 10 clients on one WABA and client #4 runs an aggressive broadcast that gets flagged, all 10 clients go offline until the restriction lifts — which can take days or never resolve for severe violations.
This is not a theoretical risk. It is the single most common way agencies lose clients and face breach-of-service disputes. The correct architecture prevents it entirely.
The correct multi-WABA architecture
The rule is absolute: one WABA per client, one phone number per WABA (in most cases). Each client's WhatsApp infrastructure is completely isolated from every other client's. A policy violation on client A has zero effect on clients B through Z.
Number: +1 555 0001
Meta billing: client card
Number: +44 7700 0002
Meta billing: client card
Number: +49 30 0003
Meta billing: agency card
ban ≠ affects others
ban ≠ affects others
ban ≠ affects others
Wrong setup vs correct setup
Centralized webhook routing — one endpoint, all clients
With separate WABAs per client, you might assume you need separate webhook endpoints per client. You don't. Every Cloud API event — regardless of which client's WABA it comes from — contains a metadata.phone_number_id field that uniquely identifies which phone number received the message. Route all clients to one central endpoint and dispatch by this ID.
phone_number_id and the normalized payload already extracted. Your router code above works immediately, with zero HMAC verification or payload parsing to implement per client.Client onboarding workflow: step by step
The end-to-end workflow to get a new client's WhatsApp number live — from their first conversation with you to their first webhook event hitting your system:
phone_number_id for routing.whatsapp_business_messaging and whatsapp_business_management permissions. Store this token in your secure key management system — it's used for all outbound messages sent on behalf of this client.phone_number_id. Send a reply from your system and confirm it appears on your personal WhatsApp. Once validated, give the client access to whatever dashboard or reports you've built for them. Their onboarding is complete.Partner access vs ownership — why it matters
This is the distinction that separates a professional agency from an amateur one. There are two ways to access a client's WABA:
- Ownership (avoid for client work): Your agency creates the WABA and the client's phone number is registered under your own Meta Business Account. You own the asset. When the client wants to leave, they have no number, no conversation history, and no continuity. This is a lock-in tactic that creates client resentment and legal exposure.
- Partner access (correct): The client creates or already has a Meta Business Account. They authorize your agency via Meta's Embedded Signup or Partner API. You get management access to their WABA without owning it. If the client terminates the relationship, they can revoke your access and continue with another agency — their number, their data, their continuity intact.
Professional agencies always use partner access. It is also better for the agency commercially: clients trust you more when they know they're not locked in, making them more likely to refer you and stay long-term. The revenue is in the ongoing management and value-added services, not in holding the number hostage.
Client billing models: three options
Meta bills per conversation to the payment method attached to each WABA. As an agency, you have three ways to structure this:
Client pays agency: $X flat
Agency risk: none
Agency invoices client: +20–50% markup
Agency risk: non-payment
Agency pays Meta: ~$40
Agency margin: ~$260
Most technical agencies building custom automation start with Model 1 (simplest, zero billing risk). Most managed service agencies — where you're running campaigns and customer service for clients — use Model 3 for predictable client invoicing and higher margins.
Revenue model: what WhatsApp services actually make
Understanding what's billable helps you structure your agency offering. There are three distinct revenue streams in the WhatsApp agency business:
- Setup fee: one-time per client for WABA registration, phone number verification, template creation, webhook configuration, and system integration. Typically $500–$2,000 depending on complexity.
- Monthly management retainer: ongoing management, monitoring quality ratings, maintaining messaging tier, template updates, support. Typically $200–$1,500/month per client.
- Value-added services: AI agent build, CRM integration, campaign management, analytics dashboards, broadcast management. Priced per project or as add-ons to the retainer.
The WhatsApp agency model is high-margin compared to social media management because the technical barrier is high (competitors can't easily replicate) and the service is mission-critical (clients can't easily churn). An agency with 15 clients at $500/month average retainer is generating $7,500/month in recurring revenue — on top of setup fees and project work.
GDPR data separation: the compliance requirement
If any of your clients serve EU customers (or you're operating under GDPR-scope yourself), data separation between clients is not optional — it is a legal requirement. Under GDPR, each client is a separate data controller. Mixing their customer data under one WABA or one database creates both parties' liability exposure.
The practical requirements for GDPR-compliant multi-client WhatsApp management:
- Separate WABAs — conversation data is isolated at Meta's level per WABA. This is solved architecturally by the one-WABA-per-client rule.
- Separate database stores — your webhook handler must write each client's conversation data to separate storage namespaces, schemas, or databases. Never mix client A's contact data with client B's in the same table.
- Data Processing Agreements (DPAs) — you need a signed DPA with each client that defines your role as data processor acting on their behalf (as data controller).
- Data deletion — when a client offboards, you must be able to delete all their contact data from your systems within the timeframe specified in your DPA. Your data model must support this from day one.
- Access controls — your system must prevent any one client's team from accessing another client's conversation data. Role-based access control at the client level.
Coexistence: keeping the Business App while using the API
Many of your SMB clients will ask: "Can I still use the WhatsApp Business App on my phone while the API is running?" As of 2026, Meta supports coexistence mode for this scenario.
Coexistence allows a phone number to be registered on both the WhatsApp Business App and the Cloud API simultaneously. Messages flow to both — the app receives them normally, and the API fires webhook events to your server. The client's team can continue handling conversations manually in the app while your API handles automation, routing, and AI responses in parallel.
The limitations of coexistence:
- Messages sent from the Cloud API also appear in the Business App. Messages sent from the Business App do not fire Cloud API webhooks (they don't reach your server).
- The Business App can only be linked on one device + up to 4 linked devices. The Cloud API has no agent limit.
- Some interactive message types (buttons, lists) sent via the API may render differently or not render in the Business App interface.
For most agency clients, coexistence is the transitional state before they fully migrate to API-only operations. Plan for it — set up the API alongside the app first, let the client get comfortable with the new workflow, then phase out direct app usage over 30–60 days.
How SocialHook works for agencies
SocialHook is built for exactly this architecture. One account, unlimited phone numbers, all events normalized to the same JSON format and differentiated by phone_number_id. Here is what you get versus managing webhooks yourself per client:
What this means operationally:
- One webhook URL to manage — not 15 or 50 separate webhook endpoints, HMAC secrets, and retry configurations per client. SocialHook handles all of that.
- Add new clients in 2 minutes — add the phone number to your SocialHook account. It starts delivering events immediately. No new infrastructure.
- Automatic retry — if your server is down during a maintenance window, SocialHook retries delivery. No events lost across any client.
- Full delivery logs — per event, per number, per client. When a client asks "did you receive my customer's message at 3:22pm on Tuesday?" — you have a timestamp-accurate answer.
- All three Meta channels — the same phone number entry in SocialHook handles WhatsApp, and you can add Facebook Messenger and Instagram DMs for the same client under the same normalized format.
Common questions
phone_number_id. Every Cloud API event includes the phone number ID in the payload — use it to look up which client the event belongs to and dispatch to client-specific handlers. With SocialHook, all client numbers deliver to one normalized endpoint automatically, already differentiated by phone_number_id. See the routing code above.phone_number_id (WhatsApp) or page ID (Facebook/Instagram). Your routing and handler code works identically for all three channels. See the Facebook and Instagram integration pages for channel-specific setup.One account.
All your client numbers.
Add every client's WhatsApp number to SocialHook. All events arrive at one normalized webhook — differentiated by phone_number_id, HMAC verified, retried on failure. Stop managing separate webhook infrastructure per client.