WeCom (Enterprise WeChat)

Connect Hermes to WeCom (企业微信), Tencent's enterprise messaging platform. The adapter uses WeCom's AI Bot WebSocket gateway for real-time bidirectional communication — no public endpoint or webhook needed.

See also: WeCom Callback for inbound webhook setup.

Prerequisites

• A WeCom organization account
• An AI Bot created in the WeCom Admin Console
• The Bot ID and Secret from the bot's credentials page
• Python packages: aiohttp and httpx

Setup

Step 1: Create an AI Bot

Recommended: Scan-to-Create (one command)

hermes gateway setup

Select WeCom and scan the QR code with your WeCom mobile app. Hermes will automatically create a bot application with the correct permissions and save the credentials.

The setup wizard will:

1. Display a QR code in your terminal
2. Wait for you to scan it with the WeCom mobile app
3. Automatically retrieve the Bot ID and Secret
4. Guide you through access control configuration

Alternative: Manual Setup

If scan-to-create is not available, the wizard falls back to manual input:

1. Log in to the WeCom Admin Console
2. Navigate to Applications → Create Application → AI Bot
3. Configure the bot name and description
4. Copy the Bot ID and Secret from the credentials page
5. Run hermes gateway setup, select WeCom, and enter the credentials when prompted

:::warning Keep the Bot Secret private. Anyone with it can impersonate your bot. :::

Step 2: Configure Hermes

Option A: Interactive Setup (Recommended)

hermes gateway setup

Select WeCom and follow the prompts. The wizard will guide you through:

• Bot credentials (via QR scan or manual entry)
• Access control settings (allowlist, pairing mode, or open access)
• Home channel for notifications

Option B: Manual Configuration

Add the following to ~/.hermes/.env:

WECOM_BOT_ID=your-bot-id
WECOM_SECRET=your-secret

# Optional: restrict access
WECOM_ALLOWED_USERS=user_id_1,user_id_2

# Optional: home channel for cron/notifications
WECOM_HOME_CHANNEL=chat_id

Step 3: Start the gateway

hermes gateway

Features

• WebSocket transport — persistent connection, no public endpoint needed
• DM and group messaging — configurable access policies
• Per-group sender allowlists — fine-grained control over who can interact in each group
• Media support — images, files, voice, video upload and download
• AES-encrypted media — automatic decryption for inbound attachments
• Quote context — preserves reply threading
• Markdown rendering — rich text responses
• Reply correlation — responses are correlated to the inbound message context
• Auto-reconnect — exponential backoff on connection drops

:::note Streaming and typing indicators The WeCom adapter delivers each response as a single complete message — it does not stream responses token-by-token, and it does not show a typing indicator. "Reply correlation" (below) only threads a response to its inbound request; it is not live streaming. :::

Configuration Options

Set these in config.yaml under platforms.wecom.extra:

Access Policies

DM Policy

Controls who can send direct messages to the bot:

WECOM_DM_POLICY=allowlist

Group Policy

Controls which groups the bot responds in:

WECOM_GROUP_POLICY=allowlist

Per-Group Sender Allowlists

For fine-grained control, you can restrict which users are allowed to interact with the bot within specific groups. This is configured in config.yaml:

platforms:
  wecom:
    enabled: true
    extra:
      bot_id: "your-bot-id"
      secret: "your-secret"
      group_policy: "allowlist"
      group_allow_from:
        - "group_id_1"
        - "group_id_2"
      groups:
        group_id_1:
          allow_from:
            - "user_alice"
            - "user_bob"
        group_id_2:
          allow_from:
            - "user_charlie"
        "*":
          allow_from:
            - "user_admin"

How it works:

1. The group_policy and group_allow_from controls determine whether a group is allowed at all.
2. If a group passes the top-level check, the groups.<group_id>.allow_from list (if present) further restricts which senders within that group can interact with the bot.
3. A wildcard "*" group entry serves as a default for groups not explicitly listed.
4. Allowlist entries support the * wildcard to allow all users, and entries are case-insensitive.
5. Entries can optionally use the wecom:user: or wecom:group: prefix format — the prefix is stripped automatically.

If no allow_from is configured for a group, all users in that group are allowed (assuming the group itself passes the top-level policy check).

Media Support

Inbound (receiving)

The adapter receives media attachments from users and caches them locally for agent processing:

Quoted messages: Media from quoted (replied-to) messages is also extracted, so the agent has context about what the user is replying to.

AES-Encrypted Media Decryption

WeCom encrypts some inbound media attachments with AES-256-CBC. The adapter handles this automatically:

• When an inbound media item includes an aeskey field, the adapter downloads the encrypted bytes and decrypts them using AES-256-CBC with PKCS#7 padding.
• The AES key is the base64-decoded value of the aeskey field (must be exactly 32 bytes).
• The IV is derived from the first 16 bytes of the key.
• This requires the cryptography Python package (pip install cryptography).

No configuration is needed — decryption happens transparently when encrypted media is received.

Outbound (sending)

Chunked upload: Files are uploaded in 512 KB chunks through a three-step protocol (init → chunks → finish). The adapter handles this automatically.

Automatic downgrade: When media exceeds the native type's size limit but is under the absolute 20 MB file limit, it is automatically sent as a generic file attachment instead:

• Images > 10 MB → sent as file
• Videos > 10 MB → sent as file
• Voice > 2 MB → sent as file
• Non-AMR audio → sent as file (WeCom only supports AMR for native voice)

Files exceeding the absolute 20 MB limit are rejected with an informational message sent to the chat.

Reply-Mode Responses

When the bot receives a message via the WeCom callback, the adapter remembers the inbound request ID. If a response is sent while the request context is still active, the adapter uses WeCom's reply-mode (aibot_respond_msg) to correlate the response directly to the inbound message. This provides a more natural conversation experience in the WeCom client.

The full response is delivered as a single message — the adapter does not stream tokens incrementally. If the inbound request context has expired or is unavailable, the adapter falls back to proactive message sending via aibot_send_msg.

Reply-mode also works for media: uploaded media can be sent as a reply to the originating message.

Connection and Reconnection

The adapter maintains a persistent WebSocket connection to WeCom's gateway at wss://openws.work.weixin.qq.com.

Connection Lifecycle

1. Connect: Opens a WebSocket connection and sends an aibot_subscribe authentication frame with the bot_id and secret.
2. Heartbeat: Sends application-level ping frames every 30 seconds to keep the connection alive.
3. Listen: Continuously reads inbound frames and dispatches message callbacks.

Reconnection Behavior

On connection loss, the adapter uses exponential backoff to reconnect:

After each successful reconnection, the backoff counter resets to zero. All pending request futures are failed on disconnect so callers don't hang indefinitely.

Deduplication

Inbound messages are deduplicated using message IDs with a 5-minute window and a maximum cache of 1000 entries. This prevents double-processing of messages during reconnection or network hiccups.

All Environment Variables

Troubleshooting