Chat integrations
Connect Multica agents to Feishu, Lark, Slack, DingTalk, or WeCom and use them from the chat tools your team already uses.
Chat integrations let the team ask an agent questions, @-mention it in a group chat, or create issues from the chat window — without opening Multica.
Feishu/Lark, Slack, DingTalk, and WeCom are supported today. They share the same session, identity, and execution mechanics but install differently.
Choose a platform
| Feishu / Lark | Slack | DingTalk | WeCom | |
|---|---|---|---|---|
| Installation | Generate a QR code in Multica and authorize by scanning it with Feishu | Create an app in Slack, then paste two tokens into Multica | Create an internal app and Stream-mode robot, then paste its AppKey and AppSecret into Multica | Create a smart bot with the long connection enabled in the WeCom admin console, then paste its Bot ID and Secret into Multica |
| DM the agent | Supported | Supported | Supported | Supported |
| Groups or channels | Triggered by @-mentioning the Bot | Triggered by @-mentioning the Bot | Triggered by @-mentioning the Bot | Triggered by @-mentioning the Bot |
| Create issues | /issue message command; creates the issue from your input as-is | /issue slash command; the agent writes up the description before creating | /issue message command; creates the issue from your input as-is | /issue message command; creates the issue from your input as-is |
| Connection | Platform long connection | Socket Mode | Stream mode | Platform long connection |
New connections are currently open only for mainland-China Feishu; existing international Lark connections keep working and can still be managed.
Each Bot is bound to one Multica agent. To use several agents on the same chat platform, connect a separate Bot for each.
DingTalk and WeCom are community-maintained: they ship in every release, but carry no official support SLA. Report problems in GitHub issues.
WeCom handles text messages today. Voice, image, and file messages get a short reply explaining that, and are not passed to the agent.
Step-by-step guides:
How a message is processed
- Multica resolves the Bot to its workspace and agent.
- In a group or channel, only messages that explicitly @-mention the Bot continue; DMs need no mention.
- Multica verifies the sender's account binding and workspace membership.
- The message joins an agent chat session, and a task is created.
- The agent's reply goes back to the original DM or thread.
Channel messages that don't @-mention the Bot never trigger the agent and are not added to its conversation context.
Ordinary messages follow this flow. /issue is a command, not a chat turn: Multica posts the result back to the originating platform but does not add the command to Multica Chat. Slack's native slash command continues through its separate asynchronous issue-creation flow.
Session isolation
- Feishu/Lark separates sessions by chat; later messages in the same chat continue the same session.
- Slack separates DMs by channel; in a channel, each thread holds its own session.
- DingTalk separates sessions by conversation; each DM or group continues its own session.
- WeCom separates sessions by chat; each DM or group chat continues its own session.
Follow-ups in a channel still need a fresh @-mention. The agent only receives messages addressed to it — it never reads the whole channel history automatically.
Account binding
The first time a member messages the Bot, they receive an account binding link. After signing in to Multica, the platform account is linked to their membership in the current workspace.
Multica only runs the agent after binding completes. Every message re-checks account binding and workspace membership; after leaving a workspace, the Bot can no longer be used to reach it.
Account binding only confirms who the sender is. Other members on the chat platform are not automatically added to the Multica workspace.
Manage connections
Workspace owners and admins can connect or disconnect Bots; for Feishu/Lark Bots, connecting and disconnecting is also open to the agent's owner. Regular members can view connected integrations and use the agents they have access to.
After disconnecting, the Bot stops receiving new messages. Existing Multica conversations and run records are kept.
Self-hosting
A self-hosted deployment must configure a 32-byte encryption key for each platform before Multica opens its connection entry point:
MULTICA_LARK_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_SLACK_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_DINGTALK_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_WECOM_SECRET_KEY=<base64-encoded 32-byte key>These keys encrypt stored Bot credentials. See Environment variables for how to generate, store, and rotate them. Multica Cloud already has this configured.
WeCom additionally requires a single backend replica: its only outbound path is the WebSocket held by one process, so replies produced on another replica are dropped. Run the WeCom-enabled backend unreplicated until cross-replica outbound routing lands.
Next steps
- Feishu / Lark Bot integration — connect an agent by scanning a QR code.
- Slack Bot integration — create a Slack app and paste its tokens into Multica.
- DingTalk Bot integration — create a Stream-mode robot and paste its credentials into Multica.
- Chat — the conversation and execution model behind every Bot.