OpenClaw Engineering, Chapter 5: Connecting Multiple Channels

In Chapter 4, we covered how the Gateway manages the agent loop and routes messages to Nodes. Now we zoom into one of the most powerful OpenClaw features: connecting to multiple messaging platforms simultaneously. Your agent doesn't live on just one channel. One instance can field messages from Telegram, WhatsApp, Discord, Slack—everywhere your users are. This chapter walks you through the setup, configuration quirks, and gotchas for each platform.

The channel adapter pattern

The core insight is that every messaging platform has its own API, message format, rate limits, and authentication model. Rather than build the agent logic around each platform's specifics, OpenClaw uses channel adapters—thin layers that normalize inbound chaos. A Telegram webhook arrives as JSON with message.text; a WhatsApp message arrives with messages[0].type and nested media objects. The adapter translates both into a single standardized message format that the Gateway understands. Your agent never sees the platform-specific noise.

This decoupling is why one agent can serve multiple channels: the Gateway receives standardized messages, routes them to the right Node, the Node doesn't care where it came from, and the response gets translated back to platform-specific syntax on the way out.

Telegram: simplicity and speed

Telegram is the easiest platform to start with. No approval process, no business registration—just create a bot via @BotFather, get a token, and you're live within minutes. The API is well-documented and the bot framework is mature. If you're prototyping multi-channel, start here.

The setup is straightforward. Search for @BotFather in Telegram, run /newbot, give your bot a display name and username (must end with _bot), and BotFather hands you a token. Paste it into your openclaw.json under the Telegram config block. Then set up a webhook—the URL where Telegram will POST messages to your Gateway. Run:

openclaw channels telegram set-webhook --url https://yourdomain.com/telegram

From then on, messages come straight to your Gateway. The configuration is minimal: token, webhook URL, message timeout, and a flag for HTML formatting in responses. Telegram lets you use <b>bold</b> and <i>italic</i> directly in responses, so your agent can format nicely without extra logic.

Common issues: webhook URL not reachable (check your firewall and HTTPS cert), bot not responding (verify the token is correct with openclaw doctor), or rate limiting (Telegram throttles bots that send too fast—implement backoff if you're bulk-messaging). If you're testing locally, use ngrok to expose your localhost to Telegram's servers.

WhatsApp: ubiquity at the cost of complexity

WhatsApp has 2 billion users. If your agent serves a global audience, you can't ignore it. But setup is heavier: you need a Meta Business Account, developer registration, business verification, phone number approval, and webhook configuration through Meta App Manager. Expect 24–48 hours for approval.

Once approved, you get three credentials: Business Account ID, Access Token (keep this secret!), and Phone Number ID. The config structure mirrors Telegram's but adds media size limits and a verification token for webhook security. One quirk: WhatsApp enforces a 24-hour message window. After a user's last message to you, you can only send template messages—pre-approved message types like order confirmations or shipping notifications. This means your agent needs to distinguish between free-form responses (allowed only within 24 hours of receiving a message) and template responses (always allowed).

If your agent wants to proactively reach a user (not responding to an inbound message), you must use templates. Create templates in Meta App Manager: order_confirmation, shipping_update, etc. Each template has placeholders for variables. Your agent's instructions should include guidance on when to use templates vs free-form responses.

Media handling is another complexity. WhatsApp supports images, video, audio, and documents, but you can't just send a URL. You need to upload the file to WhatsApp's servers first, then reference it by ID. Some agent frameworks hide this behind a helper function; in OpenClaw, your agent follows the upload-media skill if it needs to send rich content.

Discord and Slack: team and community channels

Telegram and WhatsApp are one-to-one (user to bot). Discord and Slack are inherently multi-user. When you add your OpenClaw bot to a Discord server or Slack workspace, it joins channels with many users. A single message might reach 100 people. This changes the agent's behavior: it can't assume a private conversation.

For Discord, register an app in the Developer Portal, generate a bot token, and add the bot to your server. Then configure OpenClaw with the token and server ID. Discord sends messages as JSON to your webhook. One important detail: Discord expects you to acknowledge interactions within 3 seconds. The Gateway handles this automatically, but if your agent takes longer to generate a response, Discord might show an error to the user. The Nodes/skills running in the background will continue, but the user sees a timeout. For long operations, send an immediate acknowledgement ('Processing...') and then a follow-up with the actual result.

Slack is similar but uses the Slack API and a different authentication model (OAuth token). The setup involves creating an app in the Slack API dashboard, installing it to your workspace, and getting a bot token. Slack supports rich message formatting (blocks, buttons, interactive elements), which your agent can leverage to create sophisticated UIs. However, Slack is more structured than Discord—your agent needs to understand Slack's block kit syntax to send anything beyond plain text.

Both Discord and Slack have rate limits. Slack allows roughly 1 message per second per bot. Discord's limits are more generous but still apply. Your agent should batch responses and avoid hammering the API.

Configuration and secrets management

Each platform requires credentials: tokens, API keys, webhook secrets. Never commit these to version control. OpenClaw expects credentials in environment variables or a secrets manager. The standard practice is to set them at Gateway boot time via a .env file (for local development) or through your deployment platform's secrets system (for production).

Example .env file:

TELEGRAM_BOT_TOKEN=123456789:ABCdefGHIjklmnoPQRstuvWXYZ
WHATSAPP_ACCESS_TOKEN=EAAxxxxxxxxxxxxxxxxxxxxxx
DISCORD_BOT_TOKEN=MTA5NDYyMzQ1MzQyODEyNzA4OQ.Grxxxxxxxxx
SLACK_BOT_TOKEN=xoxb-1234567890-1234567890-abcdefghijklmnop

The Gateway reads these at startup and configures the adapters. If a credential is missing, that channel is silently disabled. This is better than crashing; your agent can still work on other channels.

What's next

With your agent connected to multiple channels, the next question is: how do you extend its capabilities? Raw language understanding and simple tools are useful, but complex operations require structured knowledge. That's where Chapter 6 comes in. We'll dive into SKILL.md—how to author reusable, versioned instruction sets that teach your agent to handle sophisticated workflows, maintain dependencies, and compose skills together. Skills are the textbooks of the agent world.