Messaging Platform Integration#
Dify ships two official plugins for enterprise messaging: WeCom Bot (an endpoint-type plugin) and Lark Trigger (a trigger-type plugin). Both live in langgenius/dify-official-plugins and let teams wire Dify apps/workflows into their corporate chat environments without writing custom middleware.
| Plugin | Type | Path | Dify version |
|---|---|---|---|
| WeCom Bot | Endpoint (extension) | extensions/wecom_bot/ | β |
| Lark Trigger | Trigger | triggers/lark_trigger/ | β₯ 1.10.0 |
WeCom Bot#
How it works#
The plugin exposes an HTTPS endpoint inside Dify. WeCom (Enterprise WeChat) is configured to POST encrypted callbacks to that URL. The plugin decrypts the payload with AES-256-CBC, routes it to a configured Dify chat app, and returns the answer back to WeCom .
Key source files:
manifest.yamlβ declares the plugin astype: plugin, allocates 256 MB memory, enablesendpoint,app, andstoragepermissions.group/wecom.yamlβ endpoint group config; required settings aretoken,encoding_aes_key, and anappselector.endpoints/wecom_message.pyβ main message handler: validates signature params, decrypts payload, uploads images to Dify, invokessession.app.chat.invoke(), and returns the truncated answer (β€ 5,000 chars) .utils/crypto.pyβWeComCryptor: AES-CBC decryption + SHA1 signature verification.
Supported message types#
text, image, mixed, quote, stream. All other types return HTTP 200 silently .
Setup (three steps)#
- Create a WeCom intelligent robot application (get
Token+Encoding-AESKey). - Configure the WeCom Bot plugin in Dify, paste the credentials, and select a chat app.
- Copy the generated endpoint URL back into WeCom's callback URL field .
Lark / Feishu Trigger#
How it works#
The Lark Trigger plugin uses Dify's trigger primitive β it subscribes to Lark Open Platform webhook events and fires Dify workflows when those events arrive. All verification and optional payload decryption are delegated to the lark_oapi SDK .
Key source files:
manifest.yamlβtype: plugin, trigger-type, requires Dify β₯ 1.10.0.provider/lark.yamlβ subscription schema (4 credentials) and full list of supported event YAML files.provider/lark.pyβLarkTriggerclass;_dispatch_event()routes raw HTTP payloads throughlark.EventDispatcherHandler.events/_shared.pyβ shared helpers:dispatch_single_event(),serialize_user_identity(),serialize_user_id(),serialize_user_list().
Credentials (subscription properties)#
| Field | Required | Purpose |
|---|---|---|
lark_encrypt_key | Optional* | AES payload decryption (*required by this plugin) |
lark_verification_token | Required | Event authenticity verification |
lark_app_id | Required | Lark app identity |
lark_app_secret | Required | Lark app authentication |
Supported event domains#
IM (messages, reactions, chat membership), Drive (files, Bitable), Calendar, Contact (users, departments), VC (meetings, recordings), Meeting Rooms, Tasks, Approvals β 30+ event types total .
User Identity Mapping#
Lark#
The Lark Trigger plugin extracts three identifiers from every event and exposes them as Dify workflow variables :
user_idβ Lark internal user ID (workspace-scoped)open_idβ stable public-facing IDunion_idβ cross-workspace unified ID
These are serialized by serialize_user_identity() / serialize_user_id() and passed into the workflow as flat dictionary fields (e.g., sender_id.open_id). No automatic mapping to Dify conversation IDs occurs β workflows must implement their own routing logic using these fields.
WeCom#
The current production plugin (v0.0.7) extracts the WeCom userid from the payload for logging but does not use it for conversation scoping. Each incoming message is a stateless, independent invocation of the Dify chat app with no conversation history. Message deduplication is tracked by msgid via session.storage (key pattern: wecom_msg_{message_id}) .
A draft PR (#2828) proposes persistent multi-turn conversations using scoped storage keys (wecom_conv_{app_id}_{aibotid}_{chatid_or_userid}) and passing conversation_id into session.app.chat.invoke(), but it is not yet merged.
Known Issues#
WeCom β "user not found" (invalid_param)#
Symptom: {"code":"invalid_param","message":"user not found","status":400} returned when a WeCom message is processed .
Root cause: Dify's _get_user method in api/core/plugin/backwards_invocation/app.py cannot resolve the user_id passed by the plugin. PR #37421 (merged June 2026) tightened tenant-scoped user lookups, which broke older plugin builds that relied on looser matching.
Mitigations:
- Update the WeCom Bot plugin to the latest version.
- Check Dify server logs for the actual underlying exception (UUID format error, missing tenant, etc.).
- As a temporary workaround, pass the WeCom
useridexplicitly as the Difyuser_idparameter .