WhatsApp automations for clients: what the Meta platform actually requires

The question agencies ask before building WhatsApp automations is usually about nodes and webhooks. The questions they ask after the first client onboarding are about template approval queues and why a follow-up did not fire at hour 25. This is a walkthrough of the actual setup — the Meta account structure, the constraints built into the API, and what those constraints mean when you are running this for multiple clients rather than one of your own.

Every client is a separate Meta account

WhatsApp Business Cloud API runs through Meta's platform. Each business using it needs its own WhatsApp Business Account (WABA), registered under their own Meta Business Manager. Meta's documentation states: 'A WABA must belong to only one business portfolio. You cannot have two or more portfolios owning one WABA' (developers.facebook.com/docs/whatsapp/overview/business-accounts, checked 2026-08-30). There is no multi-client WABA. Each client is its own account.

Inside each WABA, you register one or more phone numbers. Each number gets its own Phone Number ID; the WABA itself has a separate WABA ID. New WABAs start with a cap of two registered phone numbers, which increases automatically once the business becomes verified or crosses a messaging threshold (developers.facebook.com/docs/whatsapp/phone-numbers, checked 2026-08-30). A single Meta Business Account can hold up to 20 WABAs, which is the mechanism that lets an agency nest all client accounts under one login (developers.facebook.com/docs/whatsapp/overview/business-accounts, checked 2026-08-30).

The display name on each registered number goes through a review process with three possible outcomes: PENDING_REVIEW, APPROVED, or DECLINED (developers.facebook.com/docs/whatsapp/phone-numbers, checked 2026-08-30). A declined display name requires a resubmission. For each client, expect the provisioning steps — WABA creation, phone number registration, display name review — to run in sequence before any automation touches real users.

The practical consequence for client work: each client produces at least three credential values (WABA ID, Phone Number ID, access token) that your automations need, and those values cannot be shared across clients because they point to different Meta accounts.

The 24-hour conversation window

This is the constraint that breaks the most client expectations. When a customer sends a message to a client's WhatsApp number, a service window opens and stays open for 24 hours from that message. 'If the user messages or calls you again before the timer expires, the timer resets to 24 hours,' per Meta's Cloud API documentation (developers.facebook.com/docs/whatsapp/cloud-api/guides/send-messages, checked 2026-08-30). Inside that window, the business can reply with any free-form message. Once the window closes, only pre-approved template messages can be sent.

Almost every outbound-initiated workflow — appointment reminders, lead follow-ups, order confirmations, re-engagement sequences — runs exclusively on approved templates, because the business is initiating contact rather than responding within a live window. A client who says 'send a personalised follow-up if they have not replied in 48 hours' is asking for a template workflow. Every variable in that message — name, date, appointment type — is a template parameter that must be declared and approved before the workflow can run.

The window also creates a branching condition that has to live somewhere in every workflow that sends outbound messages. The branch looks like this: check whether the timestamp of the last inbound message from this phone number is less than 24 hours old. If yes, send free-form. If no, select and send a template. That means persisting the last-inbound-message timestamp per phone number in a database — Postgres, Supabase, or similar — on every received message, with a lookup before every send. Leave this out and the workflow returns a 400 error the first time it tries to reach a customer 25 hours after they last wrote in. The message does not send, and the error is silent unless you have explicit error-node handling.

Template approval

Templates must be submitted to Meta for review before they can be used. Meta's platform defines three categories for business-initiated messages: Marketing (promotional content), Utility (transactional — order updates, booking confirmations, receipts), and Authentication (one-time codes). Category affects billing: Marketing templates are always charged per message; Utility templates are charged outside the customer service window but free within it; Authentication templates follow the same structure. Per-message pricing replaced conversation-based billing on July 1, 2025 (developers.facebook.com/docs/whatsapp/pricing, checked 2026-08-30).

Template review can take up to 24 hours (developers.facebook.com/docs/whatsapp/message-templates/guidelines, checked 2026-08-30). A rejected template cannot be edited in place — it must be resubmitted from scratch. Rejection reasons are often general. A template that passed approval can be re-reviewed later if Meta detects quality signals on the number; if it is suspended mid-operation, every workflow using it stops sending messages without proactive notification.

Templates are approved per-WABA. A template approved for one client's account cannot be reused on another client's WABA — it requires a separate submission and a separate review cycle. For a new client onboarding, this means: submit templates, wait for approval, then wire the live workflows. If your contract does not account for this dependency, the client will ask why nothing is live on day one.

The credential shape in n8n

n8n has a WhatsApp Business Cloud integration that covers sending messages to customers and receiving incoming messages via webhook (n8n.io/integrations/whatsapp-business-cloud/, checked 2026-08-30). What it does not cover: WABA provisioning, phone number registration, template submission, and business verification. Those steps happen in Meta's Business Manager before n8n is involved.

Each client's credential entry needs a WABA-scoped access token for that WABA. Meta's documentation distinguishes between temporary tokens, which 'expire quickly and are not suitable for development purposes,' and system user tokens, which the platform recommends for production use (developers.facebook.com/docs/whatsapp/business-management-api/get-started, checked 2026-08-30). The setup path is: create a system user in Meta Business Settings, assign the client's WABA as an asset, generate a token with the whatsapp_business_messaging and whatsapp_business_management permissions. Any workflow credential using a temporary token will fail silently when it expires.

Beyond the access token, each client requires: Phone Number ID, WABA ID, a webhook endpoint URL pointed at the client's trigger workflow, and a webhook verify token that Meta uses to confirm the endpoint during registration. Five credential values per client. At twelve clients, that is sixty items across twelve separate credential sets in n8n.

What fails silently in production

• Temporary token expiry. Meta's platform marks temporary tokens as expiring quickly and unsuitable for production. Check every client's credential type before go-live and replace any temporary token with a system user token (developers.facebook.com/docs/whatsapp/business-management-api/get-started, checked 2026-08-30).
• Webhook re-validation failure. Meta re-validates webhook endpoints periodically. If the verify token does not match or the URL has changed, inbound messages stop being delivered. n8n sees no error because the trigger never fires — the workflow simply does not run.
• Free-form message sent outside the 24-hour window. The API returns a 400. The message does not send. The workflow continues without error unless there is explicit error-node handling (developers.facebook.com/docs/whatsapp/cloud-api/guides/send-messages, checked 2026-08-30).
• Template suspended mid-operation. A template that passed approval can be re-reviewed if Meta detects quality signals. Suspension stops every workflow using it. There is no proactive notification.
• Number quality degradation. If recipients block or report the number at a high rate, Meta reduces daily conversation limits. A fresh number with aggressive early volume is the most common trigger.

The per-client overhead at scale

One client's WhatsApp setup is manageable. At ten clients: ten WABAs, ten credential sets, ten webhook registrations, ten template libraries, and ten quality ratings to monitor. A wording change to the follow-up template — 'your appointment' to 'your booking' — means submitting ten separate template updates and waiting for ten approval cycles, or skipping the change because the coordination cost exceeds the value.

That is the overhead that determines whether this type of work stays profitable at scale. The workflow logic is not the bottleneck. Per-client account management and per-client template versioning are.

On tooling for this work

The per-client overhead above is the argument for workflow propagation — the ability to update a template or workflow once and push it across all client instances rather than repeating the change on each. We checked taskjuice.ai/pricing and activepieces.com/pricing on 2026-08-27. Neither lists propagation as a capability. Activepieces' template management appears only inside its $36,000/year Embed tier. It is the one gap in the category that still existed as of that check.

Disclosure: we are building Tenvik, which is designed around per-client isolation and workflow propagation for automation operators. We are not a neutral source on this point. The per-client overhead documented above is a structural consequence of how the WhatsApp Business API works, regardless of which tool you use to run automations on top of it.