/v1/account/shards
The standard WhatsApp Business API Client solution runs on a single Docker container. In case you want to split the load and have multiple servers send and receive messages to WhatsApp, you can make use of our multiconnect solution on top of it.
The Multiconnect solution requires an existing high availability setup first. Please follow the High Availability documentation to set it up, then continue below.
This document covers:
Once you have your cluster set up according to the High Availability documentation, use the following request to turn on multiconnect.
Remember you need to have shard number + X Docker containers of the Coreapp running before continuing.
Multiconnect does not guarantee High Availability. Have more Corepps than shards running for High Availability.
POST /v1/account/shards { "cc": "your-country-code", "phone_number": "your-phone-number", "shards": 1 | 2 | 4 | 8 | 16 | 32, "pin": "your-pin" }
Name | Required | Description |
---|---|---|
| Yes | Country code for the phone number registered for this WhatsApp Business API Client as a string (e.g., |
| Yes | Phone number registered for this WhatsApp Business API Client without the country code or plus symbol (+) as a string (e.g., |
| Yes | Options: |
| No | The existing 6-digit PIN for two-factor verification as a string (e.g., |
201 Created : You successfully changed shard number 403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it
If you see an error when setting the shards, please try again.
GET /v1/account/shards
{ "account": { "shards": number-of-shards } }
With Multiconnect deployed the following message send rates are expected:
Message Rate (per sec) | Setup | AWS | Message Type |
---|---|---|---|
100 - 150 | Active shards: 8 | DB: | Text Message Template |
The template allows you to configure the number of active Coreapp container instances to be created. The template creates one additional Coreapp container instance to aid quick switchover in case of Coreapp failure.
The template creates the following number of instances per environment type for Multiconnect, by default, when High Availability is enabled:
The template is configured to auto scale EC2 instances depending on the memory utilization. Memory utilization increases (or decreases) with an increase (or decrease) in number of “active” Coreapp container instances. Hence, when more Coreapp instances are created, EC2 instances auto-scale accordingly. However, maximum number of EC2 instances that can be created is capped as follows:
Active Coreapp Instances | Maximum EC2 Instances |
---|---|
2 | 3 |
4 | 4 |
8 | 5 |
16 | 8 |
32 | 15 |
API request rate & number of active Coreapp instances determine number of connections to the database. With 8 active Coreapp instances and an API rate of 100 messages/second, it requires about 700 DB connections (SSL is disabled) and 1200 DB connections (when SSL is enabled). However, with 32 active Coreapp instances and an API rate of 250 messages/second, it requires about 1,700 DB connections.
In the current release, we used db.m4.2xlarge
for 8 active Coreapp instances (DB connection encryption disabled) and db.m4.4x.large
for 32 active Coreapp instances (DB connection encryption enabled). The following table provides a guidance on RDS instance class selection and the number of maximum connections it can support:
RDS Instance | Maximum DB Connections |
---|---|
| 318 |
| 636 |
| 1272 |
| 2543 |
| 1212 |
| 2424 |
| 4848 |
| 9696 |
| 19391 |
| 38783 |
| 636 |
| 1272 |
| 2543 |
| 5086 |
| 12716 |
| 20345 |
| 298 |
| 596 |
| 1192 |
| 2384 |