For setting up a WhatsApp Business API client, it is strongly recommended using the AWS cloud formation templates provided by WhatsApp. This is for two reasons:
* Not all parameters from the template are covered here
The above parameters table covers the critical parameters. But, if you require additional monitoring or insights, modify the RDS instance to apply the following optional changes:
The size of the callback queue is 100,000. If the callback/Webhooks server latency is high, these callbacks are queued in the callback queue. When the callback queue is full, the Coreapp considers it a system under heavy load and prevents you from “sending” messages. However, the Coreapp continues to accept callbacks, such as sent/delivery alerts and incoming messages, from the server, appending them to the callback queue. The Coreapp throughput to send messages becomes zero until the queue is emptied, up to a certain point. This is why it's important to configure the callback server with low latency.
To mitigate this, please set up your Webhooks in following way:
200 OKto the Coreapp before executing any business logic. If
200 OKis sent after the business logic is executed, it can increase the latency of the Webhook server.
We always recommend having Webhooks configured even if your business use case is to only send notification messages because it's important to listen to customers. The Webhoook also receives error message notifications.
When a Webhook is configured, make sure that it's configured correctly as per the above recommendations; otherwise, it can break the system when it's under heavy load. Thus, even given the importance of having Webhooks configured, it’s better to have no Webhooks when not needed for higher performance, than having incorrectly configured Webhooks.
Once the Webhook is configured, the Coreapp dispatches the inbound notifications. One of those notifications is
sent_status, which is sent when a message sent by your business is received by the server. If your business chooses to ignore this notification, you can set this parameter to
false by updating the Application Settings. By default,
sent_status is set to
sent_status does not directly impact the performance of the WhatsApp Business API client, but you may consider disabling it for following reasons:
Our recommendation is to enable the
sent_status parameter with correctly configured Webhooks and persist these alerts for report generation.
The Coreapp dispatches user messages to the Webhook. Once the messages are received, you can choose to mark messages as read (i.e., blue tick marks in the consumer version of WhatsApp). If the Webhooks are configured correctly and message volumes are within the limits, this can create a good user experience. However, if volumes are almost hitting thresholds on the Coreapp, you may not want to implement this.
If you decide to use this option, you must disable the
When a message with media is received, the WhatsApp Business API client will download the media. Once the media is downloaded, you will receive a notification through your Webhook. You can enable downloading media automatically by setting the
auto_download parameter by media type. If your business is not considering processing incoming media from users, don’t enable the
It's important to configure a monitoring setup for the Coreapp as it helps measure the performance of the Coreapp and its interactions with other system components. While you can build your own monitoring setup by making metrics and stats API calls, we strongly recommend setting up the instance monitoring provided by WhatsApp.
Media messages reduce the performance by a significant factor. Please avoid sending media message during times of demanding performance needs.
You may consider media messages if you have the option to send the same media file for many or all users (e.g., your company logo). There are a couple of ways to send media — either by media ID or by media URL. In this case, please consider sending media only by media ID because the media can be uploaded once to the Coreapp and reused many times. If you choose to send media by URL, this has to be downloaded each time.
Please note that although the upload only happens once, there are additional costly computations that need to be done in the Coreapp to send media messages, so use this option only if necessary. It is also recommended you create a flag to turn this feature off when performance bottlenecks are hit with live traffic.
It's strongly recommended you roll out your launch in a graduated manner. Always start with launching to a fraction of your users; learn the behaviors of traffic, then do a wider launch. Similarly, if you are launching globally, consider initially launching to a region with lower traffic, then gradually adding other regions.
If throughput needs are much higher than a single phone number can handle, you can consider using multiple phone numbers.
www.wa.me/$phoneURL, please add one more level of redirection via your http server. The (http) server's responsibility is to determine which phone numbers can be used to serve the incoming request and determine the correct phone number using your “split-traffic” strategy.