The WhatsApp Business API allows medium and large businesses to communicate with their customers at scale. Using the API, businesses can build systems that connect thousands of customers with agents or bots, enabling both programmatic and manual communication. Additionally, you can integrate the API with numerous backend systems, such as CRM and marketing platforms.
Businesses looking to use the API have two hosting options: On-Premises and Cloud API. In general, we recommend that the majority of businesses use the Cloud API due to ease of implementation and maintenance.
To use the Cloud API, businesses make calls to Meta’s Graph API to send messages and Webhooks to receive events, such as messages and status updates. The Graph API is a form of Remote Procedure Call expressed over HTTP, where operations and their parameters are expressed using a combination of URL parameters, headers, and request body.
A call to the Graph API from UNIX-based command lines looks like this:
curl -X POST \
'https://graph.facebook.com/v18.0
/FROM_PHONE_NUMBER_ID/messages' \
-H "Authorization: ACCESS_TOKEN" \
-d '{
"messaging_product": "whatsapp",
"to": "1650XXXXXXX",
"text": {"body" : "hi"}
}'
Compared to the On-Premises implementation, a Graph API integration relies on a different authentication mechanism (see User Access Token), a different Webhook setup process (see Setup Webhooks), and has different latencies and error rates. For more information on how to use the Graph API, see the Graph API Developer Documentation.
Versioning uses Graph API's versioning protocol. This means that all endpoint requests can include a version number, and each version will be available for roughly 2 years before it will be retired and can no longer be called.
For each registered business phone number, Cloud API supports up to 80 messages per second (mps) by default, and up to 1,000 mps by request. Throughput is inclusive of inbound and outbound messages and all message types.
Note that business phone numbers, regardless of throughput, are still subject to their WhatsApp Business Account's business use case rate limit and template messaging limits.
If you are planning a messaging campaign that requires increased throughput, you can request an upgrade to 1,000 mps for specific phone numbers by opening a Direct Support ticket with the following selections:
If approved, we will perform the upgrade at the time you specified in your upgrade request. The upgrade process itself can take up to 5 minutes. During this time, the number will not be usable on our platform.
Once a business phone number has been upgraded it will automatically be upgraded for any future throughput increases with no downtime.
Your webhook servers should be able to withstand 3x the capacity of outgoing message traffic and 1x the capacity of expected incoming message traffic. For example, if sending 1,000 mps with a 30% expected response rate, your servers should be able to process up to 3000 message status webhooks plus an additional 300 incoming message webhooks.
We attempt to deliver webhooks concurrently, so we recommend you configure and load test your webhook server to handle concurrent requests with the following latency standard:
We will attempt to re-deliver failed webhooks for up to 7 days, with exponential backoff.
To take full advantage of higher throughput, we recommend that you upload your media assets to our servers and use their returned media IDs in media messages instead of hosting the assets on our own servers and using their URLs. If you prefer (or must) host the assets on your owner servers, we recommend that you use media caching.
Use the WhatsApp Business Phone Number endpoint to get a phone number's current throughput level:
GET /<WHATSAPP_BUSINESS_PHONE_NUMBER_ID>?fields=throughput
If you migrate a business phone number that has multiconnect running 2 or more shards from On-Premises API to Cloud API, it will automatically be upgraded to higher throughput.
Each WhatsApp Business Account (WABA) has a call count rate limit. Each call made by your app to any of a WABA'S business phone numbers (i.e. the WhatsApp Business Account Phone Number node or any of its edges, such as the Messages endpoint) counts against its limit.
The current limit is 11,880,000 calls per rolling-hour for a given WABA.
For example, within a one-hour period, your app could make 11.8M calls using WABA A and another 11.8M calls using WABA B. Or, within a one-hour period, your app could make up to 11.8M total calls using a combination of different numbers owned by a single WABA.
If you reach your limit, the API will respond with error code 80007
.
Note that the Business Management API has different rate limits. See WhatsApp Business Management API rate limits.
In addition to these rate limits, we have more granular limits on individual resources such as template messages and test business phone numbers:
As a Cloud API user, you can see the number of messages sent and delivered, as well as other metrics. See Get Account Metrics for information.
Within Meta's infrastructure, the Cloud API automatically scales and adjusts to handle your workload, within your rate limit (messaging volume and number of WhatsApp business accounts).
See our Privacy & Security Overview for information.
With the Cloud API, every WhatsApp message continues to be protected by Signal protocol encryption that secures messages before they leave the device. This means messages with a WhatsApp business account are securely delivered to the destination chosen by each business.
The Cloud API uses industry standard encryption techniques to protect data in transit and at rest. The API uses Graph API for sending messages and Webhooks for receiving events, and both operate over industry standard HTTPS, protected by TLS. See our Encryption Overview whitepaper for additional details.
See our Encryption Overview whitepaper for additional details.
Key Differences | On-Premises API | Cloud API |
---|---|---|
Hosting | Individual businesses and/or BSPs need to host the API software on their own servers and in data centers. | Meta hosts the API. |
Maintenance | Individual businesses and/or BSPs need to perform API software upgrades periodically. | API software upgrades are performed by Meta and new features and security updates are available automatically on the Cloud API. Developers no longer need to do setup, maintenance or scaling work. There will be minimal code changes required to adapt to longer-term API changes. |
Costs | Businesses or BSPs need to:
| Meta pays for the hosting costs. Businesses only pay per message sent or conversation, per the rules described here. |
API Protocol | On-Premises REST API. | |
Throughput (Messages Per Second) | Send up to 70 text messages per second for single-connect. Send up to 250 text messages per second for multi-connect. Sending media messages may reduce these numbers. | Up to 1,000 messages per second. In the event of high system loads, a business may experience reduced message throughput. See Throughput. |
Certificate Management | You manage your Certificate Authority (CA) and Webhook CA certificates. | Meta manages the CA certificates. For a Webhook CA certificate, your Webhooks server needs to support HTTPS and have a valid CA-chained TLS/SSL certificate installed. Self-signed certificates are not supported. |
Media Provider API | Supported. | Deprecated. To upload media to the Cloud API, follow these steps. |
Stickerpack Management API | Supported. | Currently not supported. |
Disaster Recovery | Business/BSP needs to deploy in “high availability” model. | No SLA. |
Single-tenant vs. Multi-tenant | Single-tenant (single phone number per deployment). | Multi-tenant. Multiple phone numbers can be registered on CAPI. |
Send Message Request Processing Latency | Dependent on business deployment location (i.e. latency from their infra to WhatsApp infra in North America). | Expect the latency between receiving a request and sending a response on Meta servers to be: 90th percentile: ~1s 99th percentile: ~2s There is a plan to eventually get to 99th percentile: ~500ms |
Server Location | Dependent on business. | North America. |
Monitoring Metrics Available | Insights data available. Businesses are responsible for setting up monitoring of the on-premise solution themselves (monitoring containers included in packaging). | Insights data available. Meta monitors instance health. |
SLA (Uptime) | Not specified because it depends on an end-to-end API solution, which includes the businesses or BSP’s infrastructure. | Ongoing efforts to meet our commercially reasonable goals of 99.9% |
Support | 7x24 for critical issues on a best effort basis. | 7x24 for critical issues. Continuous work until the issue is resolved or mitigated. |
The Check Contacts and the Media Provider APIs are still in use for the On-Premises API, but they have been deprecated with the Cloud API. See more information below:
On-Premises API | Cloud API |
---|---|
Check Contacts API | For Cloud API, this call is no longer required to send messages. You can just use the person’s phone number. |
Media Provider API | To upload media to the Cloud API, follow these steps. |