Connector — Multi-Platform IM Integration

Connector is the channel through which Digital Employees connect to external instant messaging (IM) platforms. Through Connectors, a Digital Employee can receive and reply to messages on platforms such as Feishu, WeCom, and DingTalk, extending its capabilities into everyday office IM.

Overview

A Connector is bound to a Digital Employee: messages received by the published platform account are routed to the bound Digital Employee for processing.

Currently supported platforms:

Platform	Type	Description
Feishu	feishu	Self-built app on the Feishu Open Platform (WebSocket long connection)
WeCom	wecom	WeCom group bot
DingTalk	dingtalk	Enterprise internal app on the DingTalk Open Platform (Stream long connection)

More platforms (WeChat, Email) are planned.

Creating a Connector

Connectors are created under the Connector menu item in the Digital Employee detail page (the Digital Employee must be published first).

Click New Connector, select the platform type, and fill in the corresponding configuration:

Feishu

Create an enterprise self-built app on the Feishu Open Platform (open.feishu.cn) and complete the following configuration (the long-connection mode is only available for enterprise self-built apps):

1. Create the app: log in to the developer console → create an enterprise self-built app. Copy the App ID (format cli_xxxxx) and App Secret under Basics → Credentials & Basic Info.
2. Enable the bot: App Capabilities → Add App Capability → add "Bot" (required for receiving and sending messages).
3. Grant API scopes: Development Config → Permissions & Scopes → API Scopes, and enable the following three:
   • Read direct messages sent to the bot (im:message.p2p_msg:readonly)
   • Send messages as the app (im:message:send_as_bot)
   • Receive events for @-mentions of the bot in group chats (im:message.group_at_msg:readonly)
4. Subscribe to the message event: Development Config → Events & Callbacks → Event Config, set the subscription method to "Receive events via long connection", then add the "Receive messages" event (im.message.receive_v1). Note: before saving the long-connection subscription method, complete the Gendial configuration below and start the Connector first (Feishu checks whether the app has an established long connection; otherwise saving reports "no app connection info detected").
5. Publish the app: App Publishing → Version Management & Publishing → create and publish a version (enterprise accounts require admin review). Permission or event changes only take effect after a new version is published, and the availability scope must include the target users.

Then fill in App ID / App Secret when creating the Connector in Gendial (the verification token is not needed; the long-connection mode handles encryption and signature verification automatically).

Platform notes: each app can establish at most 50 long connections; when multiple clients are deployed for the same app, messages are pushed to only one random client (not an issue for single-instance Gendial deployments).

DingTalk

First create an enterprise internal app on the DingTalk Open Platform (open-dev.dingtalk.com) and complete the following configuration (requires the app-development sub-admin permission):

1. Create the app: App Development → create an enterprise internal app. Record the ClientId (i.e. AppKey) and ClientSecret (i.e. AppSecret).
2. Enable the bot: App Capabilities → add "Bot", and select Stream mode as the message receiving mode (no public callback URL needed).
3. Apply for API permissions: Permissions → search for and apply for "enterprise internal bot message sending permission" (covers direct/group message sending and file download). Permissions take effect immediately without approval, but you must publish a new version after permission changes for them to take effect.
4. Publish the app: Version Management & Publishing → publish a version, with the availability scope including the target users. Otherwise the sender identity cannot be resolved from direct messages.
5. Group chat (optional): add the bot via Group Settings → Bots in the target DingTalk group. DingTalk group chat only receives messages that @mention the bot, and does not support receiving files/voice.
6. Check the quota: the standard edition includes about 10,000 OpenAPI calls/month (outbound replies and file downloads both consume the quota); upgrade to the Professional or Exclusive edition for higher usage.

Then fill in ClientId / ClientSecret when creating the Connector in Gendial.

WeCom

Create a smart bot (AI bot) in the WeCom admin console (not the group bot added inside a chat), and enable the long-connection API mode:

1. Create the bot: log in to the WeCom admin console (work.weixin.qq.com) → Security & Management → Management Tools → Smart Bots → Create Bot (manual creation).
2. Set the visibility scope: choose which members can use the bot.
3. Enable API mode: in the bot's configuration page, enable "API Mode" and choose "Long connection" as the connection method.
4. Obtain the credentials: click "Get" in the Secret area, and record the Bot ID and Secret. Note: the Secret is a long-connection-specific key and is shown only once; regenerate it on the bot detail page if lost. It is unrelated to the Token/EncodingAESKey of the callback-URL mode.
5. Mutually exclusive modes: under API mode, "Long connection" and "Set callback URL for receiving messages" are mutually exclusive; switching to the callback-URL mode invalidates the existing long connection.
6. Group chat (optional): add the smart bot in the target group's settings, and trigger it in group chats by @mentioning the bot.

It is recommended that an enterprise super administrator creates the bot: otherwise the member userid in messages is encrypted, which affects per-member session identification.

Then fill in Bot ID / Secret when creating the Connector in Gendial.

Default Workstation (dynamic mode)

If the Digital Employee is in dynamic mode, you can select a Default Workstation: tool calls for messages received by this Connector are executed on the specified workstation.

Managing Connectors

The Connector list shows name, type, bound Digital Employee, enabled status, running status, and creator.

For each Connector you can:

• Start / Stop: control the running state (stopped Connectors no longer receive messages)
• Enable / Disable: control whether the configuration takes effect (disabling automatically stops first)
• Delete: remove the Connector (attempts to stop first)

Administrator View

Tenant administrators can view all Connectors in the tenant and perform the same management actions on the Connectors page in the admin panel.

Message Capabilities

Connectors support the following message types:

• Text messages: regular conversation
• Image messages: images are downloaded automatically for the Digital Employee to understand (Feishu downloads via the message resource endpoint; DingTalk exchanges the downloadCode for a temporary link)
• File messages: files are downloaded automatically (Feishu downloads via the message resource endpoint; DingTalk exchanges the downloadCode for a temporary link)
• Quoted messages: WeCom supports quoted message context (not yet supported on DingTalk)

Group Chat

Multiple bots can be configured in the same group chat (multiple Connectors of the same Digital Employee or multiple Digital Employees). The system maintains an independent session context for each bot to avoid message cross-talk. In DingTalk group chats, only messages that @mention the bot are received; this is DingTalk platform behavior.

Scheduled Task Notifications

A scheduled task created from a Feishu, WeCom, or DingTalk Connector private chat stores the connector_id, sender, and original private-chat target. A group task stores the sender and original group chat_id. The result is delivered only to that original private or group conversation; the system never guesses a target from a synthetic user_id, a recent contact, or the first available group. The origin snapshot remains usable even after the user runs /new.

Website-created scheduled tasks produce Web/WorkPal in-app notifications only in this release; there is no Connector destination selector. Connector delivery is at-least-once. If a Connector is stopped, only delivery is retried—the AI task is not executed again.