How to connect OpenClaw to WhatsApp, Telegram, and Slack
I have been running an OpenClaw agent on a small VPS (a virtual private server, a remote Linux machine you rent by the month) for about four months. The agent handles the kind of small but real work I used to do by hand: summarizing threads, drafting replies to routine messages, pinging me when something needs my attention. The setup I want to walk through here is connecting the agent to the three chat platforms I use most: WhatsApp, Telegram, and Slack.
This is not a deep technical guide. It is the part I wish someone had written for me: the practical “here is what to do, here is what breaks, here is what to skip” version. The official OpenClaw docs are good for the API reference. They are less good for the part where you have to decide which connection library to use and which one will silently break six weeks in.
The architecture I ended up with
OpenClaw (an open-source agent framework that runs in the background and reacts to messages, files, and scheduled events) is a server. It listens for events from one or more “channel adapters” (small pieces of software that connect OpenClaw to a specific chat platform) and produces a stream of structured events for your agent to consume. The channel adapters are the part you write or install.
There are three patterns I tried. Only one of them has been stable for me.
- Pattern A: a single channel adapter for all platforms. I tried a community-maintained adapter that claimed to support WhatsApp, Telegram, and Slack from one binary. It worked for two months and then WhatsApp changed something on the client side and the binary stopped receiving messages. I spent a weekend debugging. I do not recommend this pattern.
- Pattern B: the official OpenClaw channel adapters, one per platform. The official docs link to adapters maintained by the OpenClaw core team. They are written in TypeScript and run as Node.js services. They have been stable for the four months I have been running them.
- Pattern C: a custom adapter I wrote in Python. I wrote a custom adapter for Slack because I had a Slack-specific feature I wanted. The custom adapter is 80 lines. It uses the official Slack SDK (software development kit, a library that wraps a platform’s API). I would not have written it if the official adapter had done what I needed.
- Pattern D: a no-code bridge through a chat platform’s own automation. For some platforms, the easiest path is to use the platform’s own automation (Zapier-style webhooks, Make, n8n) to forward messages to OpenClaw. I tried this for Telegram and it worked, but the latency was noticeably higher than the direct adapter. Good for prototyping, not good for production.
I am running Pattern B for WhatsApp and Telegram, and Pattern C for Slack. The total adapter code is about 200 lines across the three services. The maintenance burden has been zero.
WhatsApp: the one that needs a real device
WhatsApp is the hardest of the three to integrate with, because WhatsApp does not have a public bot API. The community-maintained libraries connect to WhatsApp by pretending to be a real WhatsApp client. This works, but it requires you to scan a QR code (a square barcode that your phone camera reads to authenticate a new device) with a real phone, and it requires that phone to stay online.
Here is the setup I have running.
- A Raspberry Pi (a small, cheap single-board Linux computer) on my desk, with the official
whatsapp-web.js-based OpenClaw adapter. - A second phone number I bought for $5 per month, which lives in a drawer and stays plugged in. The phone number exists only for the OpenClaw agent to send and receive WhatsApp messages.
- The OpenClaw adapter authenticates to WhatsApp by reading the QR code from the Raspberry Pi’s display. I scan it once with the dedicated phone. The session persists for weeks.
The risk with this setup is that WhatsApp periodically bans accounts that look like bots. The risk is low for an account that sends fewer than 50 messages per day, which is my case. The risk is real. The mitigation is to keep the dedicated phone online and to keep the message volume low.
The simpler alternative is to use the WhatsApp Business API through a partner like Twilio. That is a paid option. For a personal agent, the unofficial approach is the one I recommend.
Telegram: the cleanest of the three
Telegram has a real bot API. The integration is straightforward. I am using the official node-telegram-bot-api library wrapped in a small OpenClaw channel adapter.
The setup is the same as the official docs, with two adjustments that took me longer than I want to admit.
- Register the bot with
@BotFatherfirst.@BotFatheris the official Telegram bot for creating and managing other bots. I tried to skip this and just call the Telegram API. It does not work. You need a bot token, and the bot token comes from@BotFather. - Use webhook mode, not polling mode. Polling mode (the adapter asks Telegram “any new messages?” every second) works. Webhook mode (Telegram pushes new messages to your adapter as they arrive) is faster and uses less bandwidth. The OpenClaw adapter supports both. Use webhook.
The full setup took about 20 minutes, including the time to read the docs carefully. It has been running for four months with zero issues.
Slack: the one I had to customize
Slack is somewhere in between. It has a real API and good official SDKs. The official OpenClaw Slack adapter is a thin wrapper around the slack-bolt framework. It works. I had to write a custom adapter for one specific feature: thread summarization.
The custom adapter listens for messages in a specific Slack channel, batches them every 15 minutes, and posts a summary back to the channel. The summarization is done by the OpenClaw agent. The custom adapter is just the Slack I/O (input/output, the code that talks to the platform).
If you do not need thread summarization, use the official adapter. If you do, the custom adapter is 80 lines of TypeScript and the only thing in it that is platform-specific is the message formatting.
What I would tell past me
If I could send a message back to the version of me that was about to set this all up, I would say three things.
- Do not start with the all-in-one channel adapter. The maintenance burden is real and the failure mode is silent. Use the official per-platform adapters.
- Telegram is the easy win. If you only have time to set up one platform, set up Telegram. The bot API is the cleanest, the docs are the best, and the failure modes are the most documented.
- WhatsApp is the platform you set up last. The unofficial approach works but it is the most fragile of the three. Make sure you actually need WhatsApp before you commit to the dedicated phone and the session maintenance.
Trade-offs
The dedicated phone for WhatsApp is a real ongoing cost. I bought a $30 phone and a $5 per month plan. The plan is the part that does not go away. The phone is now in a drawer and I do not think about it. The plan is the kind of recurring cost that I am trying to remove from my life, and this is one I have kept.
An unofficial WhatsApp integration is fragile in a way I do not fully understand. WhatsApp changes its protocol every few months. Each change has, in the past, broken the unofficial libraries. The community maintains them quickly, but there is always a window of a few days where the integration does not work. For a personal agent, this is acceptable. For a customer-facing integration, it is not.
My custom Slack adapter is 80 lines of code I now have to maintain. The maintenance has been zero so far, but I am aware that I have made a bet that the Slack API will not change in a way that breaks my code. The bet is a small one. The bet is a real one.
Bottom line
OpenClaw + the official per-platform channel adapters is a stable setup. The WhatsApp integration is the only one that requires ongoing care, and the care is mostly the dedicated phone. If you are starting from scratch, set up Telegram first, Slack second, and WhatsApp third.