Setting Up OpenClaw on WhatsApp - A Practical Walkthrough

WhatsApp is the messaging app that everyone has on their phone but nobody thinks of as a business AI channel. That's changing. More and more Australian businesses are asking us to deploy AI agents that their staff - and sometimes their customers - can interact with through WhatsApp rather than through a separate app or web portal.

The reasoning is straightforward. Your field team already uses WhatsApp. Your sales reps already have group chats with clients on WhatsApp. If you can put an AI agent into those conversations without forcing anyone to download something new or change their workflow, adoption goes through the roof.

OpenClaw makes this possible, and having deployed it across several projects, I can walk you through what the setup actually looks like, what works well, and the gotchas you should know about before going live.

How OpenClaw Connects to WhatsApp

OpenClaw connects to WhatsApp through WhatsApp Web using the Baileys library. In practical terms, this means you link a WhatsApp account to OpenClaw the same way you'd link WhatsApp Web on your desktop - by scanning a QR code. OpenClaw then maintains that session and routes messages between WhatsApp and your configured AI agents.

The OpenClaw WhatsApp documentation covers the full technical spec, but the setup process is surprisingly quick:

1. Configure your WhatsApp access policy in OpenClaw's config
2. Run openclaw channels login --channel whatsapp and scan the QR code
3. Start the gateway with openclaw gateway
4. If you're using pairing mode, approve the first incoming message

That's it. Four steps and you have an AI agent responding on WhatsApp. The simplicity is one of the things I appreciate most about OpenClaw's design - there's no Twilio account to set up, no API keys to manage, no webhook endpoints to configure and expose to the internet.

Choosing Your Access Policy

This is where the real decisions happen. OpenClaw gives you fine-grained control over who can message your agent and how. The DM policy setting controls direct message access and has four modes:

Pairing mode is the default. When someone messages your WhatsApp number for the first time, they get a pairing code. You (or an admin) approve that code, and from that point on they're authorised. Pairing requests expire after an hour, and you can only have three pending at a time. This is a nice balance between security and convenience - you're not exposing the agent to anyone who happens to have the number, but you're also not maintaining a static allowlist.

Allowlist mode is more locked down. You specify exactly which phone numbers can interact with the agent. Good for internal deployments where you know every user upfront. Less practical when you're onboarding external users regularly.

Open mode does what you'd expect - anyone can message the agent. This requires explicitly setting allowFrom to "*" so it's hard to do accidentally. Useful for customer-facing agents where you want zero friction, though you'll want to think carefully about rate limiting and abuse prevention.

Disabled turns off DM access entirely, which you might use if you only want the agent active in group chats.

For most business deployments we set up, pairing mode is the sweet spot. It gives you an approval step without requiring you to know every user's phone number in advance.

Group Chat Setup

Group chats are where things get more interesting - and where OpenClaw's design really shines compared to other frameworks I've worked with.

Group access has two layers. First, you control which groups the agent can participate in (the groups allowlist). Second, you control which users within those groups can trigger the agent (the groupPolicy and groupAllowFrom settings).

By default, the agent only responds in group chats when it's mentioned. This is the right default. Nobody wants a bot that responds to every single message in a busy group chat. Mention detection is smart too - it picks up explicit WhatsApp @mentions, configurable regex patterns, and replies to the bot's own messages.

You can change the activation mode per session with the /activation command. Set it to always and the agent responds to everything in that group. Set it to mention and it only responds when tagged. This is session-level rather than global, which means different groups can have different behaviours.

There's one subtle point worth knowing about. If you set groupPolicy to allowlist, non-allowlisted users are blocked even if they reply to a message from an allowlisted user. The system checks sender authorisation separately from mention detection. This might seem obvious, but I've seen other platforms where replying to a bot message automatically grants access, which is a security gap.

Dedicated Number vs Personal Number

OpenClaw supports both approaches, and the docs recommend using a dedicated number. I agree with that recommendation, especially for business deployments.

With a dedicated number, you get clean separation. The WhatsApp identity is clearly "your AI agent." DM allowlists are straightforward. There's no confusion about whether a message was sent by a person or the bot. The operational model is simpler.

That said, personal number mode works fine for testing and small-scale deployments. OpenClaw includes self-chat protections that prevent weird loops when the linked number is also in the allowlist. It'll skip read receipts for self-chat, ignore mention triggers that would ping yourself, and add a response prefix so you can tell which messages came from the agent. These are the kinds of edge cases that you'd discover the hard way without good framework support.

How Messages Flow at Runtime

Once the gateway is running, the message flow works like this:

The gateway owns the WhatsApp socket and handles reconnection automatically. Inbound messages get normalised into a standard envelope format - WhatsApp-specific details like message types, quoted replies, and media attachments get translated into a format that OpenClaw's routing layer can work with.

Quoted replies are handled nicely. If someone replies to a specific message, the context gets included:

[Replying to <sender> id:<messageId>]
<original message text>
[/Replying]

Media messages that the agent can't process (images, videos, audio, stickers) get replaced with placeholders like <media:image> or <media:video>. Location and contact shares get normalised into text.

For group chats, OpenClaw can inject recent message history when the bot is triggered. So if a group has been chatting for a while and someone @mentions the agent with a question, the agent can see up to 50 recent messages for context. The default limit is 50, and you can configure it or disable it entirely. The injected history is clearly marked so the agent knows which message to actually respond to.

Deployment Patterns We Use

For our managed AI agent deployments, we've settled on a few patterns that work well:

Internal team assistant. Dedicated number, pairing mode, deployed in team WhatsApp groups. The agent answers questions about company processes, pulls data from internal systems, and handles routine requests. We typically set groupPolicy to allowlist so only specific team members can trigger the agent.

Customer-facing support. Dedicated number, allowlist mode with numbers added as customers are onboarded. The agent handles first-line support queries and escalates to humans when it can't help. DM-only, no group chats. This is the most common pattern for businesses that want to offer WhatsApp support without hiring additional staff.

Field team helper. This is the one I find most useful in practice. Field workers add the agent to their existing WhatsApp groups. They can ask it questions while they're on site - "what's the procedure for X?" or "send me the spec for part number Y." The agent has access to the company's knowledge base and responds right there in the group chat. No app switching, no logging into a portal on a phone with dirty hands.

Things to Watch Out For

Session stability. WhatsApp Web sessions can drop, especially if you have WhatsApp Desktop or another web session competing for the connection. OpenClaw handles reconnection, but if you're running in production, monitor the gateway process and set up alerts for disconnections. A few minutes of downtime might be fine for internal tools, but not for customer-facing support.

Rate limiting. WhatsApp has unofficial rate limits on messages sent via Web connections. If your agent is chatty or handles high volume, you might hit these. OpenClaw doesn't currently have built-in rate limiting at the WhatsApp channel level, so you'll want to handle this in your agent configuration.

Message delivery. This isn't the official WhatsApp Business API - it's WhatsApp Web. For most use cases this is fine, but if you need guaranteed delivery receipts, message templates, or the ability to initiate conversations (rather than just respond to them), you might need the official API for those specific features.

Getting Started

The quickest way to try this out is to grab a spare phone number, set up WhatsApp on it, and run through the OpenClaw setup process. You can have an agent responding on WhatsApp within about 15 minutes.

If you want help planning a WhatsApp AI deployment for your business, or you need a managed OpenClaw setup that handles the infrastructure and monitoring for you, get in touch. We've done enough of these now to know what works and what creates headaches, and we'd rather help you avoid the headaches.