This document provides information for setting up your network and debugging potential problems.
The WhatsApp Business API client has certain network requirements for connecting to the WhatsApp servers. If your business cannot do the below, we unfortunately cannot support your WhatsApp integration.
We understand that different businesses have different network configurations and security concerns Contact Direct Support if this document is not sufficient for your setup because of any special connectivity or security requirements you may have.
The WhatsApp Business API client requires a long-lived TCP connection. Occasional requests will be made so the connection does not stay idle. However, you will have to ensure that your firewall, router, security, etc. do not terminate the long-lived TCP connections.
There are two ports used for outgoing traffic:
They are not listening or used for incoming traffic. Your business's firewall can still protect from incoming traffic as normal.
The default port for the WhatsApp Business API client is
5222. If that port is not available, the application will fallback to port
443 needs to be opened for
HTTPS at the minimum for application registration and restarts. You can leave port
5222 closed and have port
443 open, but you cannot open port
5222 and not port
It is recommended that you open both ports and allow all outgoing traffic.
The WhatsApp Business API client uses two types of protocols:
The WhatsApp proprietary chat protocol, called
chatd, is used to send the encrypted messages and information to and from the WhatsApp servers. Because it is proprietary, we ask that the port you open be on an allow list for all outgoing traffic. Some firewalls and proxies terminate non-SSL connections, which will interfere with the application's ability to connect to WhatsApp servers.
HTTPS during registration and it is necessary for restarts. We do not recommend blocking
HTTPS after registration because you never know when you will have to re-register or restart your application.
WhatsApp uses a wide range of IP addresses for its servers. You can try to allow all of the IP addresses. However, it is best to just allow all outgoing traffic and connections from the above ports.List of the WhatsApp server IP addresses and ranges (.zip file)
This list might change often. It is therefore recommended you allow all outgoing traffic from port
443, to avoid having to update this allow list in your network each time it changes.
You can add the WhatsApp servers to your allow list by hostname rather than IP address.
The WhatsApp server hostnames that the WhatsApp Business API client requires connectivity to are:
You will also need to allow access to our repository in JFrog where we host the Docker container images in order to download them.
You must use hostnames in your allow list for JFrog as IP addresses cannot be provided.
The necessary JFrog hostnames are:
Depending on your firewall and how it functions, adding the hostnames to an allow list may not work and you will need to add all the IP addresses to an allow list instead.
Examples of firewall behavior that will not work with just the hostnames on an allow list are:
In the event that your firewall exhibits one of these behaviors please proceed to use the IP addresses in an allow list.
Configure network proxies by setting the following environmental variables to the proxy you are using, then pass them to the Coreapp:
The WADebug tool can help quickly check whether the Coreapp container has access to all the required WhatsApp servers. With WADebug installed, simply run:
wadebug partial check_network
No. The WhatsApp Business API Client opens an outbound TCP connection to port 5222 or 443 on the WhatsApp servers. TCP traffic occurs over this long-lived connection. Normally firewalls classify this as allowing “outbound traffic and the established traffic.” Of course, packets will flow back and forth once the connection is established but the connection start comes from the WhatsApp Business API Client so there is no need for a rule allowing inbound connections.
Requirements depend on your load and situation. The solution will run on any internet-connected machine that runs docker. For instance, simple testing can be done on a laptop.
For single-instance production server setup, we recommend at least 250 GB SSD, 16 GB RAM, and 4 core CPU. HDD is not recommended as the I/O speeds will become bottlenecks under load.
For Multiconnect production server setup, we recommend at least 50 GB SSD, 4 GB RAM and 2 core CPU for each Coreapp/Master/Webapp container.
In most cases you should run the database on a separate physical server from the core and web containers. The database server should only be a few milliseconds of latency away from the compute machine(s).
This setup supports sending approximately 20 messages per second.