WhatsApp Business API

WhatsApp Business API is the programmatic interface to the WhatsApp Business Platform. It lets applications send and receive messages, react to events, automate conversations, manage templates and build interactive experiences.

curl -X POST "$WHATSAPP_API/messages" \

-H "Authorization: Bearer $TOKEN" \

-H "Content-Type: application/json" \

-d '{

"to": "+15550001234",

"type": "text",

"text": { "body": "Your order is on the way." }

}'

See the quickstart

Contents

• What it is

• Why the API

• How it works

• Limits and cost

• Build or buy

• Get started

Same messenger. Three different products.

WhatsApp Business API is not another WhatsApp app. It is infrastructure developers use to connect WhatsApp with software.

The Business App is a product you use. The Business API is infrastructure you build with.

If one or two people answer a handful of customers by hand, the Business App is enough.

Unofficial wrappers and emulators are not the Business API: they risk number bans, drop sessions, and are a poor fit for anything you cannot afford to lose.

The names around the API are a mess of their own. WhatsApp Business API, Cloud API and On-Premises get used as if they were one thing. They are not — and the next section is the last time this page stops on naming.

Today it's called Cloud API

WhatsApp Business Platform is Meta's name for the whole business stack on WhatsApp — numbers, accounts, templates, messaging and the rest.

Cloud API is how you talk to that platform today: Meta hosts it, you send requests and receive webhooks. You do not run a WhatsApp server.

On-Premises API was the previous, self-hosted generation. Sending messages through it has been discontinued. If a tutorial still tells you to install On-Premises, it is describing a stack you should not build.

People search for WhatsApp Business API and mean Cloud API on the Business Platform. That formula is close enough to navigate the docs — with one caveat: the platform is wider than a single messaging endpoint.

Once the names settle, the real question is why leave a free app.

Why use the WhatsApp Business API

Keep the app when you switch, let your backend see which ad started the chat, and run the number from software — not a phone.

Automation, CRM hooks and scale show up later on this page. This block is the part most articles still get wrong — or never mention.

Switching doesn't take the app away.

Teams delay the API because they think the WhatsApp Business App has to go. It does not. The same number can run in the app and in the API at once: people keep answering where they already work, and software sends notifications and handles inbound on the side. You are adding the API. You are not confiscating the chat your team already uses.

Coexistence has limits — which app features stay available, how history syncs. Check Meta's docs for the current list before you depend on a specific one. The move itself is in Get started.

Your backend sees which ad started the chat.

A Click-to-WhatsApp ad on Facebook or Instagram can open a chat with the Business App. The ad product is not exclusive to the API. What the API adds is the event: the webhook that delivers the first message also carries which ad and which source started the thread. That is enough to attribute the conversation and reply or route it in software, instead of matching ads to chats by hand.

The number lives in software.

The Business App lives on a phone. The API does not. The number is an object in your systems: no handset has to stay online, several applications and several agents can use it at once, and the channel does not depend on who is holding the device today.

How it works

Two directions, one model. If you only implement outbound, you have built half a channel.

Customer ↔ WhatsApp ↔ WhatsApp Cloud API ↔ Your backend — from the backend: CRM, AI, Support.

1. Your application sends API requests. Outbound is an HTTP call: a message, a template, a media upload. WhatsApp is not polling your server.

2. WhatsApp delivers the message. Meta's infrastructure puts it on the user's phone. You do not operate that path.

3. Webhooks send events back. Inbound messages, and the statuses that tell you whether a message was sent, delivered, read or failed, arrive as callbacks. Your application reacts. It does not ask «anything new?»

API capabilities

The WhatsApp Business API is not a «send message» endpoint with extras. This is the surface you are actually integrating.

Messaging

Send and receive WhatsApp messages.

Text is the start, not the product. The same API sends and receives images, video, audio and documents — you upload and download media rather than attaching it from a phone — plus location, contacts, reactions and stickers.

Interactive experiences

Turn a conversation into an interface.

Reply buttons, lists, call-to-action and structured replies collect a choice without parsing free text. WhatsApp Flows are native mini-forms inside the thread: booking, applications, surveys, registration, onboarding — the user does not leave WhatsApp to submit a form.

Templates and outbound messaging

Start conversations the channel will actually deliver.

A business that writes first uses templates Meta has reviewed: Utility, Authentication, Marketing. Templates exist because WhatsApp is a permissioned channel. Review happens before the first outbound message, not after a complaint. That is friction on purpose — and it is why session messages and template messages are not interchangeable in your code.

Events and webhooks

React while the conversation is happening.

Webhooks deliver inbound messages; sent, delivered, read and failed statuses; errors; replies to interactive messages; orders; call events; account events; and the click context when a conversation started from an ad. The application that ignores webhooks can send. It cannot operate.

Commerce

Put a catalog in the thread.

Product catalogs, single- and multi-product messages, carousels, orders and commerce settings let someone browse and buy without being sent to a random storefront. The catalog is a business object, not a PDF you attach.

Calling

Put WhatsApp voice on the same backend as the chat.

Receive and place WhatsApp calls from your application. Connect a PBX or a contact center — including over SIP — when the voice leg should belong to the same customer record as the thread.

Business management

Manage the WhatsApp account as software, not as a phone setting.

Phone numbers, business profiles, WhatsApp Business Accounts, templates, QR codes and account configuration are API objects. Embedded Signup is Meta's native window to connect a customer's or a branch's WhatsApp without a ticket thread. That path matters if you attach WhatsApp for other businesses, not only for yourself.

Scale and operations

Know what the channel will allow before you promise a launch date.

Messaging limits, quality rating and throughput — including automatic capacity increases — decide how much you can send. Delivery statuses and errors tell you what actually happened. The mechanics belong on this page; the current numbers live in Meta's documentation because they change.

You can't just message everyone

WhatsApp is not a list you upload. If the integration assumes a spreadsheet of numbers is enough to write first, it will be wrong on day one — in code, not only in policy.

• Customer-initiated. The person wrote first. Inside the customer-care window you can reply in free form. When the window closes, you are back to templates.

• Business-initiated. You write first only with an approved template, for a reason the person can reasonably expect.

• Opt-in. They agreed to hear from you, and they expect the kind of message you are sending. Opt-in is not a loophole around templates.

A conversation does not have to start in the inbox. A Click-to-WhatsApp ad, a QR code or a button on your site is still the user starting the thread. Some of those entry points use a different care window. The idea is stable; the timers are not — use Meta's docs, not a number from this page.

What it costs

There is no single «WhatsApp Business API price». There is a cost structure. Rates change; this shape does not.

Your total cost = WhatsApp messaging charges + platform charges or your own infrastructure

• Meta. You pay for WhatsApp messages. The amount depends on the message type, the market and Meta's current pricing model — which has already changed and will change again. This page does not quote rates.

• A platform. Providers charge a subscription, a markup on messages, a fee per number, sometimes a setup fee — often a mix. Compare the full bill, not one line on a pricing table.

• Direct to Cloud API. There is no provider invoice. There is still a bill: hosting, a database, media storage, queues, monitoring, and the engineering time to keep that stack correct when the API moves.

Prices for 1MSG are in the site header and footer. They are not repeated here.

Build it yourself or use a platform

An API gives you capabilities. It doesn't give you a product.

If you connect directly to WhatsApp Cloud API, you get the primitives to build your own WhatsApp product. You decide how messages are stored, displayed, routed and wired into the rest of your stack. Twilio, 1MSG, respond.io and the rest exist because that second half is real work — not because WhatsApp is different depending on the vendor.

WhatsApp Business API gives you: Messages, webhooks, templates, media, Flows, calling, business objects.

A platform adds: An inbox, conversation history, agent tools, CRM integrations, automation, analytics, logs, retries, user management, AI hooks, billing and developer tooling.

The difference shows up as time to production, what you pay to keep the lights on, and who is awake when webhooks fail at 2 a.m. Cloud API is not worse. It is incomplete as a product.

How you get access is a separate question from how you store messages. Three paths: your own Meta app, a BSP, or a Tech Provider. What changes is who holds the WhatsApp Business Account and the number, whether a BSP is required, and whether you can take the number elsewhere. A BSP is not mandatory. Through a Tech Provider the WABA and number can stay yours, with Embedded Signup as the connect flow. Details sit in the FAQ — this page is not a contract.

Everything you need to build on WhatsApp

The bureaucratic version of this story is a month of Meta tickets before a Hello World. The working version is a short checklist, then a first message.

What you need

• A Meta business portfolio

• A WhatsApp Business Account

• A business phone number

• Number verification

• Business verification when Meta requires it — not in every case

• An access token

• A webhook endpoint

A trial number and a sandbox cover connect, webhooks and the first message without your own line. The checklist is what production looks like, not the price of trying.

Steps

1. Create or connect a WhatsApp Business Account

2. Add your business phone number

3. Connect the API

4. Configure webhooks

5. Send your first message

6. Build your integration

Start build · Read the quickstart · Read Docs

Moving a number from the Business App

The number can move from the WhatsApp Business App onto the API. You keep the number. That is the usual fear, and it is the part with a clear answer.

Conversation history in the app does not automatically become a complete history your API can query. Treat chat history as a migration detail to confirm in Meta's docs for your setup — coexistence, a full move, or a new number are not the same case. Do not plan a cutover on the hope that every old thread will be waiting in software.

FAQ