soimy/openclaw-channel-dingtalk for OpenClaw Teams

What DingTalk Stream Mode Changes for OpenClaw

This project solves a specific integration problem: placing an OpenClaw bot inside DingTalk enterprise conversations without requiring a public IP address. The README identifies it as a DingTalk internal enterprise bot Channel plugin, and its Stream mode avoids a webhook or public entry point. That distinction matters for deployments where the OpenClaw gateway should not expose an inbound HTTP endpoint to the public network.

The intended users are OpenClaw operators who need DingTalk as a conversation surface for an AI agent. The plugin supports direct messages, group chats, and messages that mention the bot. It also handles text, images, voice, video, files, DingTalk documents, and DingTalk file cards. This is broader than a plain text relay, so teams that need conversation continuity and several media types can evaluate it without building separate DingTalk adapters.

The project does not provide a general-purpose DingTalk client or an independent AI runtime. It depends on OpenClaw and plugs into OpenClaw message handling and outbound capabilities. The README gives OpenClaw as the host platform, lists the minimum compatible version as `2026.8.1`, and identifies the package as `@soimy/dingtalk`. An installation on an older OpenClaw release therefore falls outside the compatibility boundary stated by the project.

The Message Path from DingTalk to OpenClaw

Based on the repository layout and README feature list, the plugin is organized as a TypeScript package with an `index.ts` entry point, implementation under `src/`, tests under `tests/`, and OpenClaw metadata in `openclaw.plugin.json`. The published package exposes the compiled entry point at `./dist/index.js` and declarations at `./dist/index.d.ts`. Its `exports` map also defines type declarations for consumers, which fits a package intended to be loaded by another TypeScript application.

At the conversation boundary, DingTalk events reach the plugin through Stream mode rather than through a public webhook. The plugin then participates in OpenClaw message handling. Outbound messages can represent ordinary Markdown replies or AI cards. The README specifically describes AI card streaming with structured block rendering, `taskInfo` metadata, and inline images.

There are two paths that complicate this basic flow. A reply to a quoted message can restore context, and the plugin can extract the body of common text attachments. The `dingtalk_ask_user_question` tool creates a native DingTalk interactive card when the model needs confirmation or additional fields before continuing. User submission or cancellation is injected back into the conversation as a new session message. If the current OpenClaw runtime cannot register that tool, the README says registration is skipped without preventing existing message exchange, AI cards, or feedback learning.

That fallback is useful for compatibility, but it is not silent success. An operator expecting structured forms should still verify that the tool appears in the model context. The tool's absence does not prove that credentials are valid, because the documented condition is a runtime registration limitation.

DingTalk Installation and First Configuration

Install the published package through the documented OpenClaw plugin command. The plugin name allowed in the following configuration is `dingtalk`, while the package installed from npm is `@soimy/dingtalk`.

openclaw plugins install @soimy/dingtalk

The README then recommends explicitly allowing the plugin. This configuration enables plugins, allows `dingtalk`, and supplies the DingTalk channel fields shown in the project's minimum manual example.

{
  "plugins": {
    "enabled": true,
    "allow": ["dingtalk"]
  }
,
  "channels": {
    "dingtalk": {
      "enabled": true,
      "clientId": "dingxxxxxx",
      "clientSecret": "your-app-secret",
      "dmPolicy": "open",
      "groupPolicy": "open",
      "messageType": "markdown"
    }
  }
}

The README says to upgrade OpenClaw before installation and marks `2026.8.1` as the minimum compatible version. It also recommends using one of these interactive configuration commands rather than editing configuration without support from the CLI.

openclaw onboard
openclaw configure --section channels

For development from a local clone, the repository documents a separate installation path. Run it from the cloned directory so that the link installation refers to this project.

git clone https://github.com/soimy/openclaw-channel-dingtalk.git
cd openclaw-channel-dingtalk
npm install
openclaw plugins install -l .

The README does not provide a smoke-test command or an expected sample response for the first DingTalk message. The real first-use check is therefore a configured DingTalk conversation: private messages, group messages, and bot mentions are documented capabilities, but the exact command used to initiate a session depends on the surrounding OpenClaw setup.

DingTalk Access Policies and Gateway Exposure

The minimum configuration uses `open` for both `dmPolicy` and `groupPolicy`. That is convenient for initial exploration, but the README explicitly identifies those defaults as something to change before production. It recommends `allowlist` or `pairing` as alternatives.

The choice has different operational meanings. An allowlist implies selecting permitted users or conversation participants, while pairing depends on a separate access process. The README does not reproduce the complete matching rules or permitted values in its summary. It directs readers to `docs/user/reference/security-policies.md` for the full matrix and minimum-permission examples. That file should be checked before choosing a policy rather than inferring admission behavior from the names.

Gateway RPC exposure is a separate decision. The plugin defaults `gatewayCapabilities.tools.docs` and `gatewayCapabilities.tools.proactiveSend` to disabled. Each requires explicit configuration before it takes effect. Closing these capabilities reduces the default host-callable surface, while opening them changes what OpenClaw may request through the plugin.

The local feedback learning loop is also disabled by default. This is separate from conversation admission. A deployment can therefore remain open to DingTalk messages without enabling local feedback learning. These controls should be reviewed as distinct settings rather than treated as one general security switch.

Interactive Cards, Routing, and Message Controls

The `dingtalk_ask_user_question` tool is the most distinctive workflow beyond ordinary messaging. It uses a built-in DingTalk card template, so the README says no template ID is required. The `questions` parameter provides a lightweight DSL for confirmations, single-choice questions, multiple-choice questions, and simple text input. The `fields` parameter maps to DingTalk's form variable protocol and supports more structured collection.

The documented advanced field types include `TEXT_AREA`, `NUMBER`, `SELECT`, `MULTI_SELECT`, `DATE`, `TIME`, `DATETIME`, `CHECKBOX`, `SWITCH`, `CHECKBOX_GROUP`, and `MULTI_CHECKBOX_GROUP`. This makes the tool useful for a task that cannot continue until a user makes a decision or supplies structured values. It also creates a clear lifecycle: send the card, wait for the response, then inject the result into the OpenClaw session.

The plugin also documents `/btw` for a side question that bypasses the main session lock and returns an independent quick answer. This is a different interaction model from waiting for the main generation to release its lock. Common stop commands include `停止`, `stop`, `/stop`, and `esc`, which support real-time interruption of the current AI generation.

Multi-agent, multi-bot bindings, and experimental `@` multi-assistant routing are documented as additional capabilities. Multi-agent routing is specifically marked experimental, so it carries more adoption risk than the basic private and group messaging paths. A deployment that only needs one bot and one agent should not add this routing layer without a specific requirement.

Installation Sources, Releases, and Validation Commands

The project has documented update paths for two installation methods. A ClawHub installation uses the plugin updater. A local source or link installation uses Git and restarts the OpenClaw gateway.

openclaw plugins update dingtalk

For a source installation, run the pull command in the cloned repository before restarting the gateway.

git pull
openclaw gateway restart

Mixing these paths can leave an operator unsure which copy is active, so the installation source should be identified before an upgrade. The repository records recent releases `v3.8.1` on 2026-09-23, `v3.8.0` on 2026-09-17, and `v3.7.0` on 2026-09-13. The repository is not archived, and the last push was on 2026-10-16.

For source development, the README lists these validation commands. Dependency installation should happen first, either with `npm install` or with `pnpm install` as documented.

npm run type-check
npm run lint
pnpm test

The package metadata also defines runtime and declaration builds through `build:runtime` and `build:types`, followed by the aggregate `build` script. These commands belong to repository maintenance rather than end-user installation. The README does not document a rollback command, so it would be speculative to present one.

DingTalk Quotas, Licence, and Adoption Boundaries

The most immediate operational constraint is DingTalk quota. The README cites a DingTalk platform announcement stating that the free unlimited allowance for OpenClaw calls through DingTalk `API/Webhook/Stream` was valid by default until 2026-03-31, with an application-approved exemption available until 2026-04-30 at the latest. Those dates are historical statements in the README. The actual current allowance must be checked in DingTalk Developer Console under resource management.

This plugin is therefore the wrong choice if a deployment depends on an undocumented free allowance or cannot obtain the required DingTalk platform access. Stream mode removes the need for a public entry point, but it does not remove DingTalk account, application, credential, permission, or quota requirements. The README links to dedicated permission and API consumption documents, but its summary does not enumerate every platform permission or current fee.

A webhook-based channel can be a different approach when inbound HTTP delivery and a reachable endpoint are acceptable. This project deliberately uses Stream mode instead, avoiding a public entry point. OpenClaw's general outbound channel architecture is also relevant when the requirement is simply to send messages through an existing connector rather than accept DingTalk-native events and cards.

The package is licensed under MIT. The repository also includes `CITATION.cff` and an attribution policy covering reuse, citation, and AI collaboration scenarios. This is not legal advice about DingTalk services or enterprise compliance. Deployment owners must review the repository `LICENSE` file and DingTalk's own terms separately.

Editorial conclusion

Adopt this plugin when an OpenClaw deployment needs DingTalk Stream mode, group and private messaging, document handling, or interactive question cards. Do not adopt it without checking DingTalk resource limits, deciding whether Gateway tools should remain disabled, and setting `dmPolicy` and `groupPolicy` to the intended production values. The first configuration review should verify credentials, quota status, plugin allowlisting, and the OpenClaw version compatibility boundary.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. soimy/openclaw-channel-dingtalk on GitHub