Skip to main content
We are making changes to the WhatsApp Business Platform pricing model. See Pricing Updates on the WhatsApp Business Platform.
Starting April 1, 2025, we are temporarily pausing delivery of marketing template messages to WhatsApp users who have a United States phone number. See Per-User Marketing Template Message Limits for additional information.

Message Types

You can use the API to send the following types of messages.

Customer Service Windows

Whenever a WhatsApp user messages you, a 24-hour timer called a customer service window starts (or refreshes if one has already been started). When a customer service window is open between you and a user, you can send any type of message to the user. If a window is not open between you and the user, you can only send template messages to the user, as template messages are the only type that can be sent outside of a customer service window. As a reminder, you can only send messages to users who have opted-in to receiving messages from you.

Requests

All send message requests use the POST /<WHATSAPP_BUSINESS_PHONE_NUMBER_ID/messages endpoint:
The post body varies depending on the type of message you want to send, but the payload uses the following common syntax:
The type property value in the post body payload indicates the type of message to send, and a property matching that type must be included that describes the message’s contents. For example, this is a request to send a text message to a WhatsApp user. Note that type is set to text, and a text object follows, which describes the message’s contents:
Here’s what the message would look like in the WhatsApp client if the text message was successfully delivered to the WhatsApp user:

Responses

The API will return the following JSON response if it successfully accepts your send message request without encountering any errors in the request itself. Note that this response only indicates that the API successfully accepted your request, it does not indicate successful delivery of your message. Message delivery status is communicated via messages webhooks instead.

Response Syntax

Response Contents

Webhooks

Messages sent to WhatsApp users trigger messages webhooks, so be sure to subscribe to this topic to receive message status notifications.

Commerce Messages

Commerce messages are interactive messages used in conjunction with a product catalog. See Share Products With Customers to see how to use these types of messages.

Contextual Replies

Contextual replies are a special way of responding to a WhatsApp user message. Sending a message as a contextual reply makes it clearer to the user which message you are replying to by quoting the previous message in a contextual bubble:
You can send any type of message, except for a reaction message, as a contextual reply.

Limitations

The contextual bubble will not appear at the top of the delivered message if:
  • The previous message has been deleted or moved to long term storage (messages are typically moved to long term storage after 30 days, unless you have enabled local storage).
  • You reply with an audio, image, or video message and the WhatsApp user is running KaiOS.
  • You use the WhatsApp client to reply with a push-to-talk message and the WhatsApp user is running KaiOS.
  • You reply with a template message.

Request Syntax

Post Body

Post Body Parameters

Example Request

Example of a text message sent as a reply to a previous message.

WhatsApp User Phone Number Formats

Plus signs (+), hyphens (-), parenthesis ((,)), and spaces are supported in send message requests. We highly recommend that you include both the plus sign and country calling code when sending a message to a customer. If the plus sign is omitted, your business phone number’s country calling code is prepended to the customer’s phone number. This can result in undelivered or misdelivered messages. For example, if your business is in India (country calling code 91) and you send a message to the following customer phone number in various formats:

Media Caching

If you are using a link (link) to a media asset on your server (as opposed to the ID (id) of an asset you have uploaded to our servers), WhatsApp Cloud API internally caches the asset for a static time period of 10 minutes. We will use the cached asset in subsequent send message requests if the link in subsequent message send payloads is the same as the link in the initial message send payload. If you don’t want us to reuse the cached asset in a subsequent message within the 10 minute time period, append a random query string to the asset link in the new send message request payload. We will treat this as a new asset, fetch it from your server, and cache it for 10 minutes. For example:
  • Asset link in 1st send message request: https://link.to.media/sample.jpg — asset fetched, cached for 10 minutes
  • Asset link in 2d send message request: https://link.to.media/sample.jpg - use cached asset
  • Asset link in 3rd send message request: https://link.to.media/sample.jpg?abc123 - asset fetched, cached for 10 minutes

Delivery Sequence of Multiple Messages

When sending a series of messages, the order in which messages are delivered is not guaranteed to match the order of your API requests. If you need to ensure the sequence of message delivery, confirm receipt of a delivered status in a messages webhook before sending the next message in your message sequence.

Message Time-To-Live (TTL)

If we are unable to deliver a message to a WhatsApp user, we will retry the delivery for a period of time known as a time-to-live, TTL, or the message validity period.

Default TTL

  • All messages except authentication templates: 30 days.
  • Authentication templates: 10 minutes

Customizing TTL for Authentication, Utility, and Marketing Templates

You can customize the default TTL for authentication and utility templates, and for marketing templates sent using the MM Lite API. To learn more, see Time-To-Live (TTL): Customization, Defaults, Min/Max Values, and Compatibility.

When TTL is Exceeded: Dropped messages

Messages that are unable to be delivered within the default or customized TTL are dropped. If you do not receive a delivered message webhook before the TTL is exceeded, assume the message was dropped. If you send a message that fails to deliver, there could be a minor delay before you receive the webhook, so you may wish to build in a small buffer before assuming the message was dropped.

Troubleshooting

If you are experiencing problems with message delivery, see Message Not Delivered.