Network Requirements

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.

Ports

There are two ports used for outgoing traffic:

  • 5222
  • 443

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. 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 443.

It is recommended that you open both ports and allow all outgoing traffic.

Protocols

The WhatsApp Business API client uses two types of protocols:

  • chatd
  • HTTPS

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.

WhatsApp uses 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.

IP Addresses

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)
(updated August 8, 2019, applicable beginning August 17, 2019)

This list might change often. It is therefore recommended you allow all outgoing traffic from port 5222 or 443, to avoid having to update this allow list in your network each time it changes.

Hostnames

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:

  • g.whatsapp.net
  • v.whatsapp.net
  • mmg.whatsapp.net
  • graph.facebook.com
  • static.whatsapp.net

Docker Container Images

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:

  • docker.whatsapp.biz
  • dl.bintray.com
  • akamai.bintray.com

Firewalls

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:

  • Firewalls that run a DNS query (against the DNS configured in your data center) and use the resulting IPs in the allow list;
  • Firewalls that look for outbound DNS queries from machines in the data center and use IP addresses that are seen in the response to the allow list;
  • Firewalls that look for hostnames in the HTTP/HTTPS handshake.

In the event that your firewall exhibits one of these behaviors please proceed to use the IP addresses in an allow list.

Proxies

Configure network proxies by setting the following environmental variables to the proxy you are using, then pass them to the Coreapp:

  • http_proxy
  • https_proxy

Testing with WADebug

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

FAQ

An allowlist can be created with either hostnames or IP addresses.

See the Hostnames section of the Network Requirements documentation for more information.

Yes, the TCP connection is necessary. If your business cannot open additional ports, you can use terminated SSL.

See the Network Requirements documentation for more information.

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.

Yes! by default, the WhatsApp Business API Client attempts to communicate using chatd over port 5222. For best experience, open port 5222 for all outbound traffic. This does not pose a security issue since the traffic is only outbound from your data center.

If you cannot open port 5222, the WhatsApp Business API Client attempts to use port 443. If your firewall or proxy is still terminating connections, please reach out to the WhatsApp team by submitting a question through Direct Support to debug.

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.