WhatsApp Business

On the WhatsApp side sits a WhatsApp Business Account, which lives under a Meta Business account and holds one or more phone numbers, a verified business display name, a quality rating per number, and a library of message templates that Meta reviews and approves before you may use them. Behind that sits the WhatsApp Business Platform, the official API route. Distinct from the consumer app and from the WhatsApp Business app on a phone, neither of which can be connected to a CRM.

On the AppBO side sits the conversation inbox alongside SMS, email and social channels, plus workflows that can send a message, wait for a reply and branch on it. Connected, WhatsApp becomes another channel on the contact record: an appointment reminder that arrives where the customer actually reads messages, a reply that lands in the same shared inbox as everything else, and a conversation history that sits beside the call recordings and the email thread.

The reason to treat this differently from SMS is that WhatsApp enforces a consent and messaging model in software, not merely in policy. Outside an open conversation window you may only send pre-approved templates, and only to people who opted in. Inside the window you may send freely. Everything about designing a WhatsApp automation follows from that one rule, and an integration built as if WhatsApp were SMS will be rejected by the API rather than merely frowned upon.

1. Confirm you have, or can create, a Meta Business account for the business, and that you are an administrator on it. Everything else depends on that access, and borrowing an agency's business account creates an ownership problem later.
2. Complete Meta's business verification. This requires documents proving the legal entity and its address, and it takes real elapsed time. Start it before anything that depends on it, because display-name approval and higher messaging limits are gated behind it.
3. Choose the phone number. It must be a number you control and can receive a verification code on, and it must not be currently registered to the consumer WhatsApp app or the WhatsApp Business app. If it is, delete that account first and accept that its chat history is gone.
4. Decide whether the number is new or an existing business line. Using an existing line means customers can message a number they already know, but it also means the number can no longer be used in the phone apps.
5. In the sub-account, open the integrations area and start the WhatsApp connection. The flow hands you to Meta's embedded sign-up, where you select the business account, create or select the WhatsApp Business Account, and add the phone number.
6. Verify the number with the code Meta sends, then set the display name. Meta reviews display names against its naming policy, and a name that does not match the verified business is a common rejection.
7. Grant the permissions Meta's dialog requests. Read the dialog itself for the exact scopes rather than assuming them, and complete the flow as a user who will remain an administrator.
8. Confirm the connection in the platform: the number should show as connected, with its quality rating and messaging limit visible where the platform surfaces them.
9. Build your message templates and submit them for approval. Each template has a category (marketing, utility or authentication) and the category affects what it may say and how it is treated. Write them with variables for the changing parts and submit the real wording you intend to send.
10. Wait for template approval and check the result. A rejected template usually fails on promotional content in a utility category, on placeholder text left in a variable, or on wording that reads as unsolicited. Fix and resubmit rather than working around it.
11. Build the opt-in mechanism. Consent must be explicit and must name WhatsApp specifically: a checkbox on a form, a click-to-WhatsApp entry point, or a confirmed reply. Record the consent on the contact record with a timestamp and a source.
12. Map the platform's WhatsApp channel to the contact's WhatsApp number field, and make sure numbers are stored in full international format, because WhatsApp will not accept anything else.
13. Configure the inbound side: which inbox the conversation lands in, who is notified, and what the platform does with media messages.
14. Design workflows around the session window. Use an approved template to open a conversation, and keep free-form replies to the period after the customer has responded. Build an explicit branch for what happens when they do not reply and the window closes.
15. Verify outbound template sending to a real handset that has opted in, checking that variables rendered correctly and the display name appears as approved.
16. Verify inbound: reply from the handset, confirm the message appears in the platform conversation attached to the right contact, and confirm the workflow branch for a reply fired.
17. Test the opt-out path: have the test handset block or ask to stop, confirm the platform records it, and confirm no further template sends are attempted.
18. Record who holds the business-account administrator rights, which templates are approved, and the number's current messaging limit, then review the quality rating periodically.

Platform to WhatsApp

• Template messages: the template name, its language, and the variable values that fill its placeholders.
• Free-form messages, permitted only while a customer-initiated conversation window is open.
• Media: images, documents, audio and video, subject to WhatsApp's type and size rules.
• Interactive elements where the template defines them, such as quick-reply buttons and call-to-action links.
• The destination number in full international format, and the sending number's identifier.
• Read receipts and typing indicators, where the platform exposes them.

WhatsApp to the platform

• Inbound messages from customers, with text, media and the sender's WhatsApp identifier, matched to a contact by number.
• The customer's WhatsApp profile name, which is often not the name on the CRM record.
• Message status events: sent, delivered, read, failed, with an error code when a send is rejected.
• Quick-reply button responses, which arrive as messages you can branch on.
• Conversation-window state, implicitly: a customer message opens the window.
• Template approval and rejection notifications, and quality-rating changes on the number.

What does not move

• Chat history from the consumer or business phone app. Registering the number for the API starts an empty history.
• WhatsApp groups. The API is for one-to-one business messaging; group participation is not available.
• Status updates, voice and video calls, and payments features of the consumer app.
• Free-form messages outside the session window. These are not delayed or queued: they are refused.
• Consent from another channel. An SMS opt-in is not a WhatsApp opt-in, and the platform cannot infer one from the other.
• Contact profile pictures and WhatsApp-side blocking state beyond the error you receive when a send fails.
• Template content changes without re-approval. Editing an approved template sends it back for review.

Scenario: a dental practice sends appointment reminders on WhatsApp, handles a reschedule in the open window, and handles a non-reply correctly.

1. The practice completes Meta business verification, registers a new number for the WhatsApp Business Platform, and gets the display name approved to match the practice's legal name.
2. Two templates are submitted: a utility reminder with variables for the patient's first name, the date and the time, and two quick-reply buttons reading confirm and reschedule; and a marketing template for the annual check-up recall.
3. Both are approved. The reminder is approved as utility; the recall is approved as marketing, which the team notes will be subject to different treatment and customer tolerance.
4. The booking form is updated with an explicit WhatsApp opt-in checkbox naming WhatsApp and the kinds of message the practice will send. The platform writes a consent tag and a timestamp on each contact who ticks it.
5. A patient books a hygienist appointment and opts in.
6. Two days before the appointment, a workflow sends the utility reminder template to her WhatsApp number, filling the three variables from the appointment record.
7. She taps the reschedule button. Her response arrives as an inbound message, which both opens the conversation window and triggers the workflow's reschedule branch.
8. Because the window is now open, the platform sends a free-form message with the booking link and a short sentence, without needing a template.
9. She replies asking whether a later slot exists on a specific day. A receptionist answers from the shared inbox, still inside the window, in ordinary conversational text.
10. She rebooks through the link. The new appointment replaces the old one, and the reminder workflow re-arms against the new date.
11. A second patient receives the same reminder template and does not reply at all. The window never opens, so the workflow's no-reply branch does not attempt a free-form follow-up. It waits, and the day before the appointment sends a second approved utility template, then raises a call task.
12. A third patient replies asking not to be messaged on WhatsApp again. The team records the opt-out on the contact, which removes her from the WhatsApp channel while leaving her SMS and email consent untouched.
13. A month later the practice runs the recall campaign using the marketing template, sending only to contacts with a WhatsApp consent record, in batches, while watching the number's quality rating between batches.
14. The rating stays green, so the next batch proceeds; had it dropped, the team's plan was to pause and move the remaining recall to email.

Rate limiting

Two different ceilings apply and they are often confused. There is an API throughput limit, and there is a messaging limit: a cap on how many distinct customers you may start conversations with in a rolling period, assigned per number and raised in tiers as you send quality traffic. A new number starts on a low tier, so a large launch campaign will stop mid-send. Business verification and a good quality rating are what raise the tier. Meta publishes the current tiers and thresholds in the WhatsApp Business Platform documentation. Read those figures there rather than planning against a remembered number.

Retries and idempotency

Status webhooks are delivered at least once and arrive out of order, so a handler must dedupe on the message identifier and never assume read follows delivered in the order received. Outbound sends have no universal idempotency key, so a retried send after an ambiguous timeout can deliver twice; guard workflow sends with a tag or field check rather than relying on the transport. A failed template send should not be blindly retried. Read the error code first, because a policy rejection will fail identically every time.

Field-mapping traps

Template variables are positional and typed by the template definition, so mapping the wrong field produces an approved template saying something absurd, or a send rejected for a malformed variable. Variables cannot contain newlines or certain formatting, and an empty variable fails the send outright, so every mapped field needs a fallback. Numbers must be full international format with no punctuation. The customer's WhatsApp profile name is not their real name and should not overwrite the CRM name field. Template language is part of its identity: sending the right template name in the wrong language code fails.

Duplicate creation

Duplicate contacts arise when a customer's WhatsApp number differs from the cell number on file, which is common where people keep a separate number for messaging. Decide which field is the WhatsApp number, store it explicitly, and merge on it. Duplicate conversations arise where a business runs two WhatsApp numbers and a customer messages both.

Sandbox versus live

Meta offers a test number for development that can message only a short allow-list of verified recipients and cannot be used for real traffic. It is enough to prove the plumbing and templates and nothing about delivery at scale or quality rating. The messaging-limit tier and the quality rating only exist on a live number, so plan a staged launch rather than a full switch.

Authentication expiry

The connection depends on a token tied to the Meta business account and the user who authorized it. Removing that person's admin rights, changing business-account ownership, revoking the app in business settings, or a failed re-verification can all break it. A number can also be disconnected by Meta for policy violations, and a template can be disabled or a quality rating downgraded with little notice. Watch for sends failing in bulk, which indicates an account-level change rather than a content problem, and keep at least two administrators on the business account.

What commonly breaks

• Free-form messages attempted outside the session window, which are refused. The commonest design error when a team treats WhatsApp as SMS.
• A workflow that waits for a reply and then tries to send free-form after the window has closed, leaving a conversation half-finished.
• Templates edited after approval, which sends them back for review and breaks live workflows in the meantime.
• Marketing content sent through a utility-category template, which risks the template and the number.
• A number still registered in the WhatsApp Business phone app, which blocks API registration.
• Business verification not completed, capping the messaging limit at a level too low for the campaign planned.
• Opt-in collected generically for messaging rather than explicitly for WhatsApp.
• Quality rating falling after a broad marketing send, which lowers the messaging limit and affects even the transactional reminders.
• An agency's business account holding the WhatsApp Business Account, which becomes a hostage when the relationship ends.