Before sending a message

This documentation describes how to start sending messages to your users. Remember that API messages only APP, and not another API.

Sending Messages

Message API calls are sent to the /messages endpoint regardless of message type, but the content of the JSON message body differs for each type of message (text, image, etc.).

You will see how to send each message type in its specific documentation.

Opt-in

Any communication from the WhatsApp endpoint requires an active opt-in. "Active" means that it must be triggered by a user action, such as entering a phone number or checking a box to indicate consent.

Sending messages to users without an opt-in may result in users blocking your business and suspension of your WhatsApp Business Account.

Requirements

Opt-ins must be collected before you initiate a conversation with a customer using WhatsApp. It is your responsibility, as a business, to obtain customer opt-ins and to ensure your opt-in policy complies with all laws applicable to your communications.

Business-initiated messages must be approved Message Templates. Any Message Template must comply with applicable laws and WhatsApp policies, and only be used for its designated purpose

Businesses must follow the below requirements when obtaining opt-in:

Opt-in requirements

Opt-in good practices

• Users should expect the messages they receive. Set this expectation by:

  • Obtaining an opt-in that encompasses the different categories of messages that you will send (ex: order updates, relevant offers, product recommendations, etc.).

  • Obtaining separate opt-in by specific message category. This mitigates the risk that users will block your business because they receive unsolicited messages.

• Provide clear instructions for how people can opt out of receiving specific categories of messages, and honor these requests.

• Ensure your opt-in and opt-out flows are clear and intuitive for users.

• Clearly communicate the value of receiving this information on WhatsApp.

• Monitor your quality rating, especially when rolling out new opt-in methods.

User reporting

WhatsApp has a reporting and blocking mechanism that gets activated when the user receives a message without reaching out before (in a notifications case). If the user is unaware of receiving notifications this might lead to an increase in blocked numbers or users that want to opt-out.

The best way to avoid user reporting while starting campaigns via WhatsApp is ensuring there is a clear and easy opt-out in the template message, so the user can easily opt-out instead of reporting or blocking your number.

User reporting leads to low quality rating of the number, which leads to lower messaging limits, accounts restrictions and eventually the account being blocked from the WhatsApp Business API.

WhatsApp allows users to report spam or to even block the number - a quality signal

Handling Webhook Notifications

Before sending any messages, ensure that you have setup a server endpoint to handle WhatsApp Webhook Notifications asynchronously.

See our Best Practices for designing Integrations documentation for more details.

Capacity Rate Limits

Capacity rate limiting is imposed on each available API endpoint and will return the appropriate HTTPS error codes (e.g., 429, 503, etc.) depending on the state of the system.

Two forms of capacity rate limiting are currently supported:

• Request rate limiting — Request rate limiting is the throttling of incoming requests on an API endpoint. When the number of requests per second limit is reached, the endpoint will start returning a 429 error code.

  • Beginning with v2.25.3, the request rate limit for the messages endpoint is 50 requests per second with bursts allowed up to 150 requests per second.

  • For versions prior to v2.25.3 and all other endpoints, the request rate limit is 20 requests per second with bursts allowed up to 60 requests per second.

• Concurrent rate limiting — Concurrent rate limiting is the throttling of incoming requests when the Coreapp itself is under heavy load (e.g., job queue size grew too large). At this point, the endpoint will start returning a 503 error.

When you hit either of these capacity rate limiting scenarios, you should halt any further requests and slow the pace of your API requests. If you start seeing many capacity rate limit errors, it would be advisable to build a queue on your end to throttle the requests.