OpenClaw + Telegram + Lark Integration Research Report

Research date: 2026-03-13

Goal: Run OpenClaw with both Telegram and Lark so the same gateway can receive messages, dispatch agents, and send operational updates across channels.

Current setup

The current OpenClaw environment already has Telegram running normally. Lark is connected through a webhook bridge rather than the native OpenClaw integration.

Current Lark architecture

The current path is:

Lark -> Cloudflare Tunnel -> bridge.py -> OpenClaw Gateway

The bridge receives Lark events, forwards them to OpenClaw, handles group reply rules, and performs message deduplication.

This works, but it has costs:

• extra service to maintain
• Cloudflare Tunnel requirement
• more moving parts during outages
• limited access to native OpenClaw Lark features

Native Lark integration

OpenClaw can integrate with Lark directly through a long-lived WebSocket connection. That removes the public webhook endpoint and reduces the deployment surface.

Native integration can support:

• direct messages
• group messages with bot mentions
• interactive card messages
• bot message sending
• media file handling

Migration plan

Step 1: Create or update the Lark app

Create a Lark enterprise app, enable bot capability, and get the App ID and App Secret.

Step 2: Configure permissions

The app should include permissions for receiving and sending IM messages, reading message resources, and accessing files if the workflow needs media handling.

Example permission areas:

im:message
im:message:send_as_bot
im:message:readonly
im:chat.members:bot_access
im:resource

Step 3: Enable event subscription

Use Lark's long-connection event subscription and add the message receive event.

Step 4: Configure OpenClaw

Use the OpenClaw channel setup flow:

openclaw channels add

Select Lark or Feishu, then enter the app credentials.

Step 5: Restart and verify

Restart the gateway, send a direct message and a group mention, then confirm that OpenClaw receives and responds through the native channel.

Telegram considerations

Telegram is already the more mature channel in this setup. The main follow-up is policy tuning:

• whether direct messages should be open or paired
• whether groups should be allowlisted
• whether streaming should be partial or full
• whether proxy settings are still required

Recommended target architecture

The target architecture is:

Telegram  -> OpenClaw Gateway
Lark      -> OpenClaw Gateway
Other IM  -> OpenClaw Gateway

OpenClaw becomes the single channel hub. Claude Code or other local agents can then be launched behind it through ACP.

Recommendation

Move Lark from webhook bridge mode to native integration.

The migration reduces maintenance cost, avoids public tunnel dependency, and makes the Lark channel match the Telegram channel more closely in operational behavior.

Suggested priority:

1. Switch Lark to native integration.
2. Re-check Telegram DM and group policies.
3. Add advanced Lark capabilities such as file upload and user identification only after the basic channel is stable.