هذه الصفحة بالإنجليزية

لم نترجمها بعد. بقية الموقع متاحة بلغتك.

Product documentation

Configure a messaging channel

Channel settings combine provider credentials with controls for messages forwarded to the external platform.

Provider credentials

After you choose Slack, Telegram, DingTalk, or Feishu, complete the fields shown for that provider. The form is the source of truth for required values: obtain them from the matching app or bot configuration in the external platform, and do not substitute credentials from another workspace or provider.

Secret values use the protected credential path. During editing, an unchanged masked value can preserve the stored secret according to the form contract. Enter a new value only when you intend to rotate that credential, and update any paired fields together when the form requires it.

DingTalk and Feishu configurations can include an App ID and App Secret. Feishu can also show Encrypt Key and Verification Token fields. Slack and Telegram display their own provider-specific fields; follow the labels and validation in the current form rather than reusing the DingTalk or Feishu field model.

Message display

  • Filter thinking: requests that reasoning content not be forwarded.
  • Filter tool messages: requests that tool-call messages not be forwarded.
  • Show tool details: requests detailed tool output when tool messages are shown.

When Filter tool messages is enabled, the saved value of Show tool details is forced off because there are no tool messages to expand.

Important limitations

  • These switches control message presentation; they do not change what tools an Agent is authorized to use.
  • Channel type is read-only after creation.
  • Saving valid credentials does not by itself prove end-to-end delivery; the external app or bot configuration must also be active and reachable.
  • The details view does not provide a generated public link, token, delivery metrics, or live health status.
Last verified: 2026-09-11Initial draft complete