Manage every WhatsApp number from one workspace.
Monitor connection health, review conversations, and control team access without switching tools.

Welcome back
Sign in with your administrator account to continue.
Monitor connection health, review conversations, and control team access without switching tools.

Sign in with your administrator account to continue.
Monitor every registered WhatsApp number.
| WhatsApp number | Number ID | Display name | Status | Quality / type | Actions |
|---|
| No. | Sender | Message | WhatsApp number | Received | Status | Actions |
|---|
| No. | Contact | Call | Result | Duration | WhatsApp number | Started |
|---|
| No. | File | Sender | Conversation / group | WhatsApp number | Date & time | Actions |
|---|
| No | Contact | Phone | Organization | Labels | Related number | Message sync | Actions |
|---|
| Member | Role | Number access | Teams | Status | Actions |
|---|
| Role | Access level | Permissions | Users | Actions |
|---|
| No. | Name | Key | Created by | Created | Last used | Expires | Status | Actions |
|---|
Generate a key to connect your first service, script, or external integration.
No API key saved.
Stored only in this browser. Saving a key switches the current login to machine access.
X-API-Key header on API requests.X-API-Key: wac_live_your_generated_keyChatGPT / OAuth: choose OAuth and Dynamic Client Registration. Client ID and secret are created automatically; token endpoint authentication is none. Use the tenant custom domain to select the workspace; the root domain asks for its slug.
API key / no browser login: generate a dedicated key above, then send it in X-API-Key or Authorization: Bearer YOUR_KEY. Choose Streamable HTTP. No OAuth client ID or secret is needed. The key selects its own workspace, including on the root domain.
Replace PASTE_YOUR_API_KEY_HERE with a key from this workspace. For AnythingLLM, merge into anythingllm_mcp_servers.json in storage/plugins and refresh Agent Skills. For Cline, merge into cline_mcp_settings.json. Keep existing servers and do not share a configuration containing your real key.
Both methods enforce the connected account's current role scopes, number ownership, and Own Data Only restrictions. API-key access is authenticated access, not anonymous access.
Authenticate with X-API-Key. Use a phone number or, for QR-linked sessions, a group JID ending in @g.us as the recipient. A fixed Idempotency-Key is allowed: identical payloads are deduplicated for 10 minutes, while changed messages are sent normally.
Keep one fixed destination in the URL and reuse the same idempotency namespace.
Send directly to a WhatsApp phone number from the selected connection.
Available for QR-linked numbers using a group JID ending in @g.us.
Put the destination and message in the URL when the integration cannot send JSON.
/webhooks/{numberId}/messages.| Received | Number / recipient | Payload | Status | Diagnostic |
|---|
| Created | Endpoint / event | Status | Response | Action |
|---|
--file. Running both copies can disconnect numbers or duplicate sends. WhatsApp may still require a new QR scan.Before copying: log in through SSH as your normal deployment user, with Docker access. You do not need to write to /root. Commands use $HOME, which means the home folder of the user running the command on that server. The examples use source project whatsapp-cloud, environment .env.docker, target directory $HOME/source/whatsapp, and target project whatsapp-live. The target directory and project must be brand new. Adjust all examples consistently if you choose different names. Add every deployment overlay with --file to each source command, using the same configuration as your deployment. Use private/encrypted storage with several times the installation size free. Stop if any command fails; do not skip verification.
Run this first. Resolve any reported blockers before continuing. Confirm the Compose project name is whatsapp-cloud before step 3.
node scripts/serverMigration.js plan --env .env.docker
Run as the same user who ran step 1. This creates whatsapp-transfer.migration-key in your home folder, readable only by you. It refuses to overwrite an existing key. If one already exists, keep it for its existing backup or choose a new filename in every command. No output on success is normal. Never paste the key contents into this page or a chat.
(
umask 077
set -C
openssl rand -base64 48 > "$HOME/whatsapp-transfer.migration-key"
)
Disable external auto-deploy/restart jobs first. Run each line only after the previous one succeeds. Save the migration ID printed by freeze/export. Large installations can take time while volumes, images and the encrypted payload are captured; progress appears in the terminal. Leave the old server stopped; do not run ./deploy or Compose up.
node scripts/serverMigration.js freeze --env .env.docker --confirm whatsapp-cloud &&
node scripts/serverMigration.js export --env .env.docker --out "$HOME/whatsapp-transfer.wcserver" --passphrase-file "$HOME/whatsapp-transfer.migration-key" &&
node scripts/serverMigration.js inspect --in "$HOME/whatsapp-transfer.wcserver" --passphrase-file "$HOME/whatsapp-transfer.migration-key"
Using SFTP or your secure file-transfer tool, copy whatsapp-transfer.wcserver from the old user's home folder into the new user's home folder. Transfer whatsapp-transfer.migration-key separately into that new home folder; run chmod 600 "$HOME/whatsapp-transfer.migration-key" on the new server. Copy this release's scripts/serverMigration.js into a working directory there, keeping the scripts/ subfolder. No full application deployment is needed first. Home folder names may differ between servers. Compare the bundle SHA-256 on both servers with the checksum printed at export:
sha256sum "$HOME/whatsapp-transfer.wcserver"
Open SSH on the new server, in the working directory containing scripts/serverMigration.js. The target directory and project must not already exist. These commands start only data services, not WhatsApp connections. MongoDB TTL expiry is paused automatically during this offline verification and restored at activation.
TARGET_DIR="$HOME/source/whatsapp"
TARGET_PROJECT="whatsapp-live"
node scripts/serverMigration.js restore --dir "$TARGET_DIR" --project "$TARGET_PROJECT" --confirm "$TARGET_PROJECT" --in "$HOME/whatsapp-transfer.wcserver" --passphrase-file "$HOME/whatsapp-transfer.migration-key" &&
node scripts/serverMigration.js start-data --dir "$TARGET_DIR" &&
node scripts/serverMigration.js verify --dir "$TARGET_DIR"
Edit before running: replace MIGRATION_ID_FROM_EXPORT with the ID printed earlier. Confirm verification succeeded, review pending jobs/webhook retries, and prepare DNS, HTTPS and tunnel/proxy routing for the root hostname and every tenant hostname. The target web service starts during activation, so test each public hostname immediately afterward. The old installation and its auto-restart jobs must remain stopped.
node scripts/serverMigration.js activate --dir "$HOME/source/whatsapp" --confirm MIGRATION_ID_FROM_EXPORT --source-stopped --queues-reviewed --infrastructure-reviewed
After activation, open the new site and check each public route, login, each tenant, WhatsApp numbers, chat history, contacts, files, MCP and webhooks. The generated compose.migration.json pins the captured images; Git pull or plain Compose up alone does not install new application code. For later updates, pull a committed revision in the restored checkout and run ./deploy update. Its migration-aware path rebuilds only the application image within the existing project and preserves migrated volumes. Do not destroy the old server yet.
Do not restart the source while the target is running. If the target accepted new messages/files, reconcile them first: rollback does not merge them into the old server. Replace the migration ID below before running.
If freeze fails, export does not run: there is no new bundle to checksum. The error now names failing services; web shutdown logs identify the pending stage. Data services may intentionally remain running. Do not delete credentials, volumes or the migration journal. Use the recovery command below only with the target stopped. After a successful source-resumed, apply the fix and follow README → “Retrying after a failed freeze” to archive the resumed journal privately before a fresh compatibility check.
# On target, stop it without deleting its volumes:
docker compose -p whatsapp-live -f "$HOME/source/whatsapp/compose.migration.json" stop --timeout 300
# On source, only after reconciling any new target data:
node scripts/serverMigration.js resume-source --env .env.docker --confirm MIGRATION_ID_FROM_FREEZE --target-stopped --rollback-reviewed
Rollback does not merge new target messages or files. Keep target volumes for reconciliation. For ongoing maintenance, use the generated compose.migration.json, not an unrelated fresh deploy configuration. Keep migration state private: it contains credentials.
Current tenant state across the platform.
Subscriptions grouped by their current state.
Waiting, active, and failed jobs across background workers.
Key signals from operators, billing, and operations.
Latest immutable administrative events.
Manage application preferences and operational data.
Download the operational database, contacts, and File Manager content as one portable archive.
Merge missing records and files, skip duplicates, and map old session IDs to connected numbers.
Permanently clear messages, chats, and cached groups. Accounts, roles, branding, and linked numbers are preserved.
Export linked Meta business accounts and phone credentials in a passphrase-encrypted archive, then import them on another Whatsapp Cloud installation.
Export every linked number at once, or choose only the Meta connections you need.
Upload an encrypted connection archive created on another server.