OpenClaw on WhatsApp without risking your own number

OpenClaw’s WhatsApp channel links your gateway to a WhatsApp account as a linked device, using the Baileys library and a QR code. The account is yours, so a ban is yours too. OpenClaw’s docs recommend a dedicated second number: a SIM, an eSIM or a prepaid line. If you would rather not own that number, a managed one can connect over HTTP with a short bridge.

How does OpenClaw’s WhatsApp channel work?

OpenClaw is an open-source (MIT) self-hosted gateway that connects chat apps to AI agents. Its WhatsApp channel is “production-ready via WhatsApp Web (Baileys)”, in the docs’ words, and the gateway owns the linked session and its reconnect loop. The docs state there is no separate Twilio WhatsApp channel. The facts in this article come from OpenClaw’s docs and repository as read on 19 October 2026.

The setup is short:

1. Install the plugin: openclaw plugins install @openclaw/whatsapp.
2. Link the account: openclaw channels login --channel whatsapp. Login is QR-only, so on a headless server you need a reliable way to get the live QR to your phone.
3. Start the gateway with openclaw gateway.

The default dmPolicy is pairing. An unknown sender gets a pairing request, and you approve it with openclaw pairing approve whatsapp <CODE>. Requests expire after one hour and each account holds at most three. Other policies are allowlist (only numbers in allowFrom), open and disabled. The channel handles direct chats, groups, images, video, audio and documents, and it sends typing presence while it works and read receipts by default.

Linking happens by scanning from a phone, so the number lives on a phone, and OpenClaw rides along as a linked device. That detail drives most of what follows.

Why does OpenClaw want a second number?

OpenClaw’s docs recommend a dedicated number for access-control reasons, and WhatsApp’s own pages describe a risk that OpenClaw’s WhatsApp and setup pages do not discuss.

WhatsApp’s page defines unofficial apps as fake WhatsApp apps and websites made by third parties, and it names neither OpenClaw nor Baileys. OpenClaw is a third-party client that links as a device, so assume the warning applies to you. A second number caps the damage: if WhatsApp bans the account, it is the assistant’s number and not the one your family and clients use.

Personal-number mode is a supported fallback. Onboarding then writes dmPolicy: "allowlist", your own number in allowFrom and selfChatMode: true, and the docs warn that a liveness check sent to your own number can become agent input unless you set selfChatMode: false.

How do you get the second number?

The 14-day rule comes from WhatsApp’s linked devices page, which also says linked devices work without the phone online and disconnect after 30 days of inactivity. If you already run OpenClaw on your personal number, add the assistant as a named account instead of reinstalling: openclaw channels login --channel whatsapp --account assistant. Accounts live under channels.whatsapp.accounts.<id>, and each keeps its own credentials.

How do you stay unbanned with OpenClaw?

No setting is documented as ban-proof, and WhatsApp decides. These habits fit what the docs and WhatsApp say:

• Use an allowlist. Set dmPolicy: "allowlist" and allowFrom to the people who should reach the agent. The default pairing mode already makes you approve unknown senders.
• Keep the tool policy tight. OpenClaw’s guide says a connected agent can, depending on policy, run commands, use files and message people on your behalf. An agent that texts people who never wrote to it is cold outreach from your number, one of the signals that Why WhatsApp bans numbers covers.
• Back up before relinking. Copy ~/.openclaw/credentials/whatsapp/<accountId>, then openclaw channels logout and openclaw channels login, as the troubleshooting docs describe.
• Warm the number first. How to warm up a new WhatsApp number separates what is known from community practice.

Can OpenClaw use a managed number such as whasp?

Not through the WhatsApp channel. That channel is WhatsApp Web through Baileys, and OpenClaw’s docs list no other WhatsApp transport. whasp is an HTTP API: inbound messages arrive at your webhook and one API call replies. So OpenClaw has no built-in way to take whasp as its WhatsApp. It does have two documented doors.

The Gateway’s OpenAI-compatible endpoint. OpenClaw’s /v1/chat/completions is disabled by default and runs a normal agent turn. The model field names an agent (openclaw/<agentId>), and an OpenAI user string gives a stable session, so repeated calls continue one conversation. A bridge connects the two sides:

import { createServer } from "node:http";
import { Webhook } from "standardwebhooks";

const wh = new Webhook(process.env.WHASP_WEBHOOK_SECRET); // whsec_... from whasp
const seen = new Set(); // dedupe on event id (use a real store in production)

async function askOpenClaw(user, text) {
  const res = await fetch(`${process.env.OPENCLAW_URL}/v1/chat/completions`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.OPENCLAW_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: process.env.OPENCLAW_AGENT ?? "openclaw/default",
      user, // same value per conversation = same OpenClaw session
      messages: [{ role: "user", content: text }],
    }),
  });
  if (!res.ok) throw new Error(`OpenClaw answered ${res.status}`);
  const data = await res.json();
  return data.choices?.[0]?.message?.content ?? "";
}

async function sendToWhasp(to, text, eventId) {
  const res = await fetch("https://api.whasp.ai/v1/messages", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.WHASP_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": eventId,
    },
    body: JSON.stringify({ to, text: text.slice(0, 4096) }),
  });
  if (!res.ok) throw new Error(`whasp answered ${res.status}`);
}

createServer(async (req, res) => {
  if (req.method !== "POST") return res.writeHead(405).end();
  const chunks = [];
  for await (const chunk of req) chunks.push(chunk);
  const body = Buffer.concat(chunks).toString("utf8"); // raw body, before parsing

  let event;
  try {
    event = wh.verify(body, req.headers);
  } catch {
    return res.writeHead(401).end();
  }
  res.writeHead(204).end(); // acknowledge now, work after

  if (event.type !== "message.received" || seen.has(event.id)) return;
  seen.add(event.id);
  const { number, chat, text } = event.data.message;
  if (!text || /^(STOP|UNSUBSCRIBE|OPTOUT|CANCEL|END|QUIT)$/.test(text.trim())) return; // whasp handles opt-out

  try {
    const answer = await askOpenClaw(`whasp:${number}:${chat}`, text);
    if (answer) await sendToWhasp(chat, answer, event.id);
  } catch (err) {
    console.error(event.id, err.message);
  }
}).listen(8790);

We ran this against stand-ins for both APIs, built from OpenClaw’s and whasp’s documentation. We did not run it against a live OpenClaw gateway. To use it, enable gateway.http.endpoints.chatCompletions.enabled, register the bridge’s public HTTPS URL with PUT /v1/webhook, and set WHASP_WEBHOOK_SECRET, WHASP_API_KEY, OPENCLAW_URL (the docs use http://127.0.0.1:18789), OPENCLAW_TOKEN and OPENCLAW_AGENT. The signature check and duplicate handling are explained in WhatsApp webhooks for AI agents.

Three things to watch. First, OpenClaw’s docs call this endpoint full operator access to the gateway: keep it on loopback or a private network, so that only the bridge can call it. Second, texts from strangers are untrusted input, so point OPENCLAW_AGENT at a dedicated agent whose tools you have restricted. OpenClaw’s README tells you to treat inbound messages as untrusted input. Third, OpenClaw now sees a generic API client, not a WhatsApp channel. Its pairing, allowlists, groups, reactions, typing and voice notes do not apply, and whasp has its own limits: users write first, and there are no groups, typing indicators or outbound voice notes.

A channel plugin. OpenClaw’s docs say to build a channel plugin when you integrate an external messaging network with its own webhook delivery or outbound transport. That gives native routing and access control, at the price of writing and maintaining TypeScript against the plugin SDK. We have not built one.

What to do next

Pick the route by who will text the agent:

• Only you. A prepaid SIM or eSIM plus OpenClaw’s own channel is a reasonable setup, as long as you accept that the number is the risk. Keep dmPolicy on allowlist.
• A few people you know. The same setup, with each person in allowFrom or approved through pairing, and a tool policy you would be comfortable with if one of them were careless.
• Customers or strangers. Put the account where a ban does not touch your own number: a managed number through the bridge above, or the official WhatsApp Business Platform if your bot qualifies.

Unofficial WhatsApp APIs compared lays out the trade-offs between the self-run options, and WhatsApp MCP servers shows another way to give an agent a number.