A developer's guide to the WhatsApp Business Platform: account setup, the Cloud API, templates and the 24-hour window, secure webhooks, delivery statuses and scaling.
In this article
- 01What the WhatsApp Business Platform is
- 02Step 1: Set up the accounts
- 03Step 2: Understand the 24-hour window and templates
- 04Step 3: Send your first message
- 05Step 4: Receive webhooks securely
- 06Step 5: Track statuses and failures
- 07Opt-in, quality and messaging limits
- 08Interactive messages and flows
- 09Architecture for a production integration
- 10Common integration mistakes
- 11Build or use a platform
What the WhatsApp Business Platform is
The WhatsApp Business Platform lets software send and receive WhatsApp messages on behalf of a business: order updates, appointment reminders, OTPs, support conversations and chatbots. It is different from the WhatsApp Business app, which a person uses on a phone. The platform is accessed through an API, and today most new integrations use the Cloud API, which Meta hosts, so you do not run any messaging servers yourself.
You can integrate directly with Meta or through a Business Solution Provider (BSP) such as Twilio, Infobip, Gupshup or 360dialog. A BSP adds onboarding help, dashboards and sometimes a simpler API, at an extra cost. Direct integration gives you the most control. The concepts below apply either way. Our WhatsApp Business API explainer covers the business side.
Step 1: Set up the accounts
Everything hangs off a Meta business portfolio (formerly Business Manager). Inside it you create a WhatsApp Business Account (WABA), add a phone number and create an app in the Meta developer dashboard with the WhatsApp product enabled. Plan these details early, because some steps involve review:
- A phone number that is not active on the consumer WhatsApp or WhatsApp Business app, or one you migrate deliberately
- A display name that matches your brand, which Meta reviews
- Business verification, which raises messaging limits and enables some features
- A system user with a long-lived access token for your servers, instead of a temporary token tied to a person
Step 2: Understand the 24-hour window and templates
WhatsApp is strict about who messages whom. When a customer messages you, a customer service window opens for 24 hours from their latest message. Inside it, you can reply with free-form messages: text, images, documents, buttons and lists. Outside it, you can only start a conversation with a pre-approved message template.
Templates are submitted for approval with placeholders for variables, such as an order number or a date, and fall into categories: marketing, utility (such as order and account updates) and authentication (one-time passcodes). Pricing depends on the category and the recipient's country, and Meta has changed its pricing model over time, so check the current rates before estimating costs. Write templates that are clearly useful, since low-quality marketing templates hurt your number's quality rating.
Step 3: Send your first message
Sending is an authenticated HTTPS POST to the Graph API messages endpoint for your phone number ID, with a bearer token. The JSON body includes messaging_product set to whatsapp, the recipient's number in international format and a type. For a template, the type is template, with the template name, language code and the values for each placeholder. For a reply inside the service window, the type can be text, image, document or interactive.
The response contains a message ID, not a delivery confirmation. Store that ID with your own record, such as the order or ticket, because delivery and read updates arrive later through webhooks and reference it. Our JSON formatter is handy for checking request bodies while you build.
Step 4: Receive webhooks securely
Incoming messages and status updates arrive as webhooks to an HTTPS endpoint you register. Registration starts with a verification request: Meta sends a GET with hub.mode, hub.verify_token and hub.challenge, and your endpoint returns the challenge if the token matches the one you configured.
- Verify every POST using the X-Hub-Signature-256 header, an HMAC SHA-256 of the raw request body computed with your app secret
- Respond with 200 quickly and process the payload asynchronously through a queue
- Deduplicate by message ID, since the same event can be delivered more than once
- Do not assume ordering: a read status can arrive before a delivered status
- Log raw payloads for a short period to debug integration issues
Step 5: Track statuses and failures
Status webhooks report sent, delivered, read and failed for each outgoing message. Failed statuses include an error code explaining why, such as a recipient who is not on WhatsApp, a template that was paused or a message outside the service window. Map these codes to actions in your system: fall back to SMS or email, alert the team or mark the contact as unreachable.
Read receipts depend on the recipient's privacy settings, so treat read as a bonus signal, not a guarantee.
Opt-in, quality and messaging limits
You need a customer's opt-in before sending them business-initiated messages, and the opt-in should make clear what they will receive. Store when and how each opt-in was given, and honor opt-outs immediately, including replies like STOP.
New numbers start with a limit on how many customers they can message in a rolling 24-hour period. The limit rises as you send higher volumes with good quality. If many users block or report your messages, your quality rating drops, templates can be paused and limits can fall. Sending fewer, more relevant messages is the most reliable way to grow.
Interactive messages and flows
Plain text is not the only option. Reply buttons and list messages let customers choose instead of typing, which makes bots far more reliable, and WhatsApp Flows provide structured multi-screen forms for tasks like booking an appointment. Use them to keep conversations on rails, and hand over to a human agent whenever the customer asks or the bot is unsure.
Architecture for a production integration
Keep WhatsApp behind a small messaging service in your backend rather than calling the API from many places. That service owns templates, tokens, rate limiting, retries, opt-in records and the mapping between WhatsApp message IDs and your business records. Other parts of the product publish events, such as order shipped, and the messaging service decides which template to send.
- A queue between webhooks and processing so spikes do not drop events
- Retries with backoff for temporary API errors, with idempotency on your side
- A shared inbox or CRM integration for human agents
- Dashboards for delivery rate, failure codes and opt-outs
Common integration mistakes
Most WhatsApp integration problems come from a handful of avoidable mistakes:
- Using a temporary access token in production, which expires and silently stops all messages
- Processing webhooks synchronously, so slow handlers cause timeouts and repeated deliveries
- Sending marketing content through utility templates, which risks template rejection or pausing
- Storing phone numbers in inconsistent formats, creating duplicate contacts
- Letting a bot loop on messages it cannot understand instead of handing over to a person
- Forgetting that customers reply hours later, after the context in your system has changed
Build or use a platform
Building directly on the API makes sense when messaging is core to your product. If you mainly need campaigns, a shared inbox and simple chatbots, an existing platform is faster. Nexzem offers both routes: our WhatsApp automation solution for custom integrations and our NexChat product for teams that want a ready inbox and campaign tool.



