How to Set Up WhatsApp Cloud API Step by Step

To set up WhatsApp Cloud API for production, prepare a Meta business portfolio, a Meta app, a WhatsApp Business Account, and a phone number the business can register. Then configure managed access and webhooks, test inbound and outbound events, and decide who owns failures before customers use the number.

A developer test number is useful for the first request. It is not the production setup. The part that usually takes care is agreeing who owns the Meta assets, which number will be used, and what happens after an API call succeeds or fails.

Decide who owns the business assets

Start with ownership, not code. The Meta business portfolio should belong to the company that is accountable for the number and the customer communication. Record who can administer the portfolio, the Meta app, the WhatsApp Business Account and the number.

This matters when an employee leaves, an agency changes or a token needs to be revoked. If one external login is the only path into the setup, the API may work today while the business has no dependable way to maintain it later.

Use Meta's current setup guide to confirm the exact verification, review and permission steps for the access your app needs. Those requirements can change and can differ between a business connecting its own assets and a provider onboarding customer assets.

Choose the number before configuring the app

Decide whether the number is new, already used in the WhatsApp Business app or connected through another provider. Do not unregister or migrate a working number as an experiment. Check the current onboarding path, expected downtime, message history limitations and rollback options first.

If the team wants to keep using the business app as well as Cloud API, review the WhatsApp coexistence checklist before changing the number. Eligibility and onboarding behavior should be confirmed in the live Meta flow, not assumed from an old tutorial.

Keep the number under business control. Make sure the team can complete any required verification and that the display name, business identity and customer facing purpose are ready for review.

Create the Meta app and connect WhatsApp

Create or select the Meta app that will own the integration and add the WhatsApp product. In the WhatsApp setup flow, create or select the WhatsApp Business Account and connect the chosen phone number.

Early tests normally expose identifiers and temporary access suitable for development. Store the WhatsApp Business Account identifier and phone number identifier as configuration, not as text pasted through unrelated tools. Keep credentials out of browser code, documents and chat messages.

Before continuing, send one controlled test to a permitted recipient and record the request identifier. A successful response means Meta accepted the request for processing. It does not prove delivery, a reply or a useful customer outcome.

Register the phone number carefully

Follow Meta's current phone number documentation for registration and status. Check the number in the WhatsApp Manager view as well as through the API. The two views help separate an application error from an asset or account state.

Confirm the display name state, number state and ownership before sending production traffic. If registration fails, keep the error and the asset identifiers together. Repeating setup steps without knowing which asset failed can create more uncertainty.

Do not treat number registration as customer readiness. The business still needs templates for the applicable proactive messages, a consent and opt out process, an inbox owner and a recovery path when delivery fails.

Set up access without creating a hidden dependency

Use only the permissions needed for the intended workflow. Name the person or system responsible for issuing, storing, rotating and revoking production access. A temporary developer token and a production credential should not be managed as though they have the same lifetime or risk.

Keep secrets in a server side secret store. Do not put them in public JavaScript, screenshots, tickets or analytics. Test revocation and rotation before launch so the team knows how to recover without leaving the number unmanaged.

When an agency or technology provider performs the setup, write down which assets the business owns and what access the provider retains. The answer should still be clear six months later.

Make webhooks a production gate

Outbound sending is only half of the integration. Configure a public HTTPS callback, complete Meta's verification step and subscribe the correct WhatsApp Business Account fields. Meta's webhook documentation is the current source for the event setup.

Test an inbound customer message and the relevant status events. Save the provider event identifier before performing an irreversible action so a retry does not create a duplicate customer update or message. Acknowledge valid events quickly and move slower work to a reliable queue.

Make failed events visible. A webhook that returns a successful HTTP response but silently drops the work is harder to operate than one that records a clear failure and owner.

Test what happens when things go wrong

Run a small test plan before opening the number to customers.

Also check consent, opt out handling and the route to a person. Technical delivery does not make an unsolicited or poorly governed message acceptable.

Connect the number to the customer workflow

An API connection should end in owned customer work. Decide where a new conversation appears, how it is assigned, what context the agent sees and when automation must stop. A shared WhatsApp inbox gives the team one place to own replies, while the developer documentation explains how DripTell can exchange useful events with connected systems.

Keep the DripTell role proportionate to the problem. Meta controls WhatsApp access and delivery. DripTell can keep the conversation, owner and customer context together after those channel events arrive. The original CRM or commerce system should remain authoritative for the data it owns.

Measure readiness before launch

Do not use the number of successful API requests as the launch metric. Review whether inbound messages are captured, status events are processed, duplicates are suppressed, failed events are recoverable and a customer can reach the right person.

Useful operating measures include webhook processing success, duplicate events blocked, time to recover a failed event, conversations without an owner and replies that reached a human with the earlier context attached.

Launch with a controlled audience first. Read the actual events and handoffs, fix unclear ownership, and only then expand traffic.

Questions people ask before setup

Do I need a Meta business portfolio

For a normal production business setup, yes. It provides the ownership context for the app, WhatsApp Business Account and phone number. A developer test number can support early testing but does not replace production ownership.

Can I use a number that is already in the WhatsApp Business app

Possibly, but do not assume the migration or coexistence path. Check the current Meta onboarding flow and the number's eligibility before changing a working account.

What proves the setup is ready

Prove more than sending. Show that inbound messages and status events arrive, retries are safe, access can be rotated, failures are owned and a customer reply reaches the correct team with context.

Does DripTell provide Meta permissions

No. Meta controls WhatsApp Business Platform access and its review processes. DripTell can support the customer workflow after the business has the required channel access.