Skip to main content
If your users or developers sit behind a corporate firewall, web proxy, or VPN that restricts outbound traffic, add the CometChat domains below to your allowlist so chat, calling, AI agents, moderation, and media work. All of it is outbound traffic (HTTPS/WSS plus the few ports listed under Ports). The one exception is webhooks: if you use them, your webhook endpoint must accept inbound HTTPS from CometChat.
Allow by domain, not by IP. CometChat runs on elastic cloud infrastructure, so its IP addresses change without notice and IP-pinning will eventually break your integration. If your security policy requires fixed IP ranges, contact CometChat — they are provided on request, not published, because they are not static.

​
The domain families

CometChat’s own hosts are on four domains. Most runtime services run on the first three (for redundancy and edge routing), so allow all three; cometchat.com carries the dashboard and website. The JavaScript Calls SDK also fetches from two third-party hosts, listed under UI Kit, calling and sample app assets.

​
Quickest option — allow the wildcards

Allowing these wildcard domains, together with the outbound ports below, covers every CometChat-owned host. If your app uses the JavaScript Calls SDK, also allow the two hosts outside these domains listed under UI Kit, calling and sample app assets (fonts.googleapis.com and fonts.gstatic.com):
Some proxies treat *.cometchat.io as matching only one label deep, but several CometChat hosts are deeper: <appId>.api-<region>.cometchat.io is two labels under the apex, and the call signalling host <appId>.xmpp.rtcv5-<region>.cometchat.io is three. If your firewall matches only one level, use its “match all subdomains / any depth” option (or add *.*.cometchat.io and *.*.*.cometchat.io) so per-app and calling hosts aren’t missed. The same applies to cc-cluster-2.io and cc-edge-2.io.
If wildcards are acceptable in your policy, you can stop here. The sections below list the individual hosts for teams that must allowlist per-subdomain. New hosts can be added as CometChat adds services, so the wildcards above are the only list guaranteed to stay complete.

​
Full per-service list

<region> is your app’s data region — us, eu, or in (find it in your app’s endpoint on the Dashboard); <appId> is your App ID. Allow only the region(s) your apps run in. Where a service lists three families, allow all three.

​
Runtime — chat, calling, AI, moderation

Each of these runs on all three runtime families — cometchat.io, cc-cluster-2.io, cc-edge-2.io: So, for example, Admin APIs = <appId>.api-<region>.cometchat.io, <appId>.api-<region>.cc-cluster-2.io, and <appId>.api-<region>.cc-edge-2.io.

​
Extensions

Each extension you enable is served from its own host on all three runtime families, with no App ID prefix: <extension>-<region>.<family>. For example, polls-<region>, reactions-<region>, stickers-<region>, whiteboard-<region> (Collaborative Whiteboard) and document-<region> (Collaborative Document), plus the shared extensions-<region>. Allow the host for every extension your app uses, on each family.

​
Runtime — cometchat.io only

​
Calling (voice and video)

The media servers themselves have no hostname to allowlist. CometChat sends their IP addresses during call setup, and media flows to them over UDP (see Ports). If your firewall can’t allow those UDP flows, media falls back to the TURN relay on TCP 443. Allowing turn.rtcv5-<region>.cometchat.io is what keeps audio and video working on a locked-down network: without it, a call can ring and connect but carry no audio or video. Apart from the Calls REST API, these hosts exist on cometchat.io only, not on cc-cluster-2.io or cc-edge-2.io.

​
Media & uploaded files (cometchat.io)

​
CDN

cdn.cometchat.io

​
UI Kit, calling and sample app assets

Your users’ devices fetch these at runtime, so allow them wherever the app runs, not only on your team’s network:

​
Metrics

metrics-<region>.cometchat.io, metrics-<region>.cc-cluster-2.io, metrics-<region>.cc-edge-2.io

​
Visual Chat Builder

apivcb.cometchat.io, apivcb.cc-cluster-2.io, apivcb.cc-edge-2.io

​
Dashboard, tooling & website (your team, not end users)

​
Ports

All of this traffic is outbound. Which ports you need depends on where the CometChat client runs: Flutter SDK v4 and Flutter UI Kits v4 and v5 connect through native SDKs from v3.0 onward, so they’re in the first row too. To check an older app, look at the CometChat SDK version it was built with: pro-android-chat-sdk 2.x on Android, or CometChatPro 2.x on iOS.
Ports 5222 and 7443 are only for native iOS and Android SDK v2.x. Browsers, the WebSocket-based SDKs and native SDKs from v3.0 onward never use them, and a browser can’t even test them. For those apps, don’t ask users or IT to check 5222 or 7443. Check that 443 is open and that the proxy allows WebSocket (WSS) upgrades.
An open port 443 isn’t always enough. A proxy that blocks or buffers WebSocket (WSS) upgrades, or a firewall that blocks UDP 10000–20000 without allowing the TURN fallback (turn.rtcv5-<region>.cometchat.io on TCP 443), is the most common cause of a client stuck on “connecting” or a call that rings but has no audio or video. If your firewall must pin destinations, the media and TURN IP ranges are provided by CometChat on request, not published as a static set. Contact us.

​
Webhooks (inbound)

If you use webhooks, CometChat sends HTTPS POST requests to your webhook URL. Your server, not your users’ devices, must accept inbound HTTPS on the port in that URL (usually 443). CometChat doesn’t publish a fixed list of source IP addresses, so secure the endpoint with the webhook’s Basic Authentication rather than an IP allowlist. If your policy requires source IPs, contact CometChat.

​
Push notifications (delivered by Google and Apple)

Push is delivered through the platform providers, so allow their domains, not a CometChat one:
  • FCM (Android / Web) — Google’s push endpoints, e.g. fcm.googleapis.com.
  • APNs (iOS) — Apple’s push endpoints, e.g. api.push.apple.com.
See each platform’s own network requirements for the authoritative, complete list.

​
Installing the SDKs (build and CI networks)

The domains above are for running the app. If your build or CI network is also locked down, the CometChat packages are pulled from the standard registries plus CometChat’s package host: dl.cloudsmith.io (path /public/cometchat/cometchat) hosts the iOS and Android binaries and the React Native calls library.

​
Notes

  • Client traffic is outbound only (see Ports). The only inbound traffic is webhooks, sent to your own server.
  • Region scoping: allow the -<region> subdomains for your app’s region; allow us, eu, and in together only if you operate apps in more than one region.
  • On-premise deployments host these services on your own domains instead — see On-Premise Deployment.
  • Check the status page if traffic is allowed but a service still seems unreachable.