A production WhatsApp Cloud API integration needs a secure receiving endpoint, durable message processing, and an explicit sending policy. Sending a test message proves connectivity; it does not prove that billing, customer permissions, routing, retries, or agent handoff will work. Build the smallest complete customer workflow before adding automation.
Define the first supported interaction
Choose one inbound interaction and one outbound event. An illustrative appointment business might receive a customer's reschedule request and send a confirmation after staff approve a new time. Write down who owns the appointment state, who replies, and what happens if the messaging service is unavailable.
Keep the appointment database authoritative. WhatsApp reports communication activity; it should not become the only record that an appointment changed. A customer's message saying they paid also should not replace payment verification.
Select a direct or provider arrangement before implementing credentials and callbacks. The Cloud API vs BSP comparison identifies the operational work behind that choice.
Establish a test environment
Follow Meta's current Get Started flow to create the app and connect the appropriate Messaging account. Use the API Setup screen's test sender and permitted recipient configuration. Record the phone number ID and account ID returned by your own setup.
Generate the temporary token, send the supplied test message, and reply from the receiving device. Confirm your test webhook receives the inbound event and the expected status events. This exercises both directions of the connection.
Keep this environment separate from customer data. Test assets and temporary credentials are not production credentials. Avoid hard-coding a Graph API version copied from a tutorial; choose a supported version, record it in configuration, and review its changelog before upgrading.
Meta's current account model separates number identity from messaging assets. Follow the identifiers and supported endpoints documented for the account and rollout phase you actually have. Do not rename or replace IDs based solely on an old guide's terminology.
Move credentials and account setup into production
Set up the real business-controlled number and the assets required by the chosen onboarding route. Confirm number control, administrator access, approved business information, the applicable publishing or review requirements, and a working payment arrangement. Requirements can depend on the integration and access scope, so test with the production account before scheduling a launch.
Replace the temporary token with the supported production system-user arrangement and required asset permissions. Store tokens and the app secret in a server-side secret manager. Give only the services that need them access, document rotation, and test the failure response to revocation.
Last verified: October 2026. Current Meta documentation charges applicable service messages as well as templates, subject to allowances and exemptions. Confirm billing for the production Messaging account; a successful test does not establish that customer replies will be delivered without a payment method. Policy and rates can change.
Implement two different webhook checks
The GET verification request proves that you control the callback endpoint. Check the expected subscription mode and verification token, then return the challenge value. Keep the token confidential, but do not confuse it with the app secret or treat it as authentication for later POST requests.
For POST notifications, validate X-Hub-Signature-256 against an HMAC-SHA256 computed with the app secret over the original request bytes. Capture those bytes before JSON parsing or middleware transforms them. Re-serializing parsed JSON can change whitespace or escaping and invalidate the signature.
Reject malformed or invalid signatures before processing. Compare validated signature bytes with a constant-time comparison and avoid exposing secrets or raw payloads in error logs. Put a request-size limit at the ingress so verifying a payload cannot consume unbounded memory.
These checks solve different problems. Passing the setup challenge does not prove that an arbitrary message claiming to be a Meta event is authentic.
Acknowledge only after durable acceptance
Use a short receiving path:
HTTPS callback
-> validate signature and payload shape
-> save event and deduplication identity durably
-> acknowledge receipt
-> process through a worker
-> update CRM and conversation state
This is an architectural outline, not a complete implementation. If durable storage fails, do not acknowledge work you cannot recover. Once an event is saved, retries should return the appropriate successful acknowledgment without repeating business actions.
Parse every relevant item in the event batch. An implementation that always reads only the first entry can silently discard work. Validate the sending account and number against your configured tenant mapping before applying the event to a customer record.
Deduplicate inbound messages using the provider message identity plus your account scope. Delivery statuses need a separate event identity or a carefully defined composite key because one outbound message can legitimately receive multiple status updates. Preserve those events rather than discarding every repeated message ID.
Our webhook design guide develops these recovery choices further.
Make outbound sending a durable workflow
Save a business intention with a unique internal operation key, recipient, purpose, permitted template or message type, and current state. A worker checks whether sending is still allowed before calling the API. Save the returned provider message ID and subsequent status events.
A successful API response is acceptance, not evidence that the user read the message. Keep accepted, delivered, read, failed, and unknown states meaningful in the operator interface. Avoid treating absent read evidence as proof of delivery failure.
Use bounded retries for errors the current API documentation identifies as retryable. Preserve permanent failures for correction. If a network timeout leaves acceptance unknown, an internal outbox alone cannot guarantee exactly-once delivery through Meta. Reconcile using available provider events and operational evidence; route sensitive ambiguous sends for review rather than claiming duplicate prevention you have not verified.
Enforce the sending policy at execution time
Maintain the latest qualifying inbound user timestamp and calculate the customer service window on the server. Before sending delayed work, recheck the window, current consent, suppression status, and template availability. A job valid when queued can become invalid while waiting.
Outside the supported non-template window, use an approved template appropriate to the purpose. Do not replace a rejected transactional message with promotional copy merely to get a send through. Pause work when the template or account becomes unavailable.
Keep a direct escalation path for customers who need human help. When an agent takes over, suppress conflicting automation for that conversation. The pricing and messaging windows guide explains why permission to send and charging are separate checks.
Test the release as an operator
Exercise an invalid signature, duplicate event, delayed status, expired token, unavailable CRM, opt-out, window expiry, and ambiguous send timeout. Verify that each produces an understandable state and a recovery action.
Use restricted logs containing operation IDs and failure codes rather than full customer message bodies. Alert on growing queue age, repeated authorization failures, and missing processing progress. Give staff a way to pause automation while preserving inbound enquiries.
Release to a small set of consenting recipients, inspect the account's actual usage and billing, and verify staff can complete the workflow manually. Expand after the application can explain what happened to a message and what it will do next.