WeCom inbound channel and extension boundary

An inbound channel turns an external messaging platform into a task entry point. The channel adapter verifies and decrypts the platform callback, normalizes the sender and message, selects a bound route, creates or continues a conversation, and replies according to the platform’s delivery rules.

Current public implementation

BailingHub Core v0.5.1 includes a WeCom inbound implementation. Feishu and DingTalk can follow the same kind + config + route_key adapter mechanism, but they are not built-in, selectable channels in this fixed release.

Do not describe an extensible architecture as an already supported platform. Each new channel must still implement its own URL verification, signature or encryption flow, message normalization, reply window, and asynchronous delivery behavior.

WeCom message path

WeCom callback
  -> verify the platform signature and decrypt the message
  -> extract the member UserID and content
  -> select the channel-bound route_key
  -> create or continue a BailingHub conversation
  -> reply within the platform window, then use configured async delivery

WeCom sends a verification request when its administrator saves the callback URL. Public reachability, Token, and EncodingAESKey must all match or the handshake will fail.

How identity reaches the business system

After verification, a WeCom member UserID can become a trusted, platform-scoped subject such as wxuid:<userid>. The wecom:* namespace is used for conversation keys, not for the trusted subject passed to business tools. A wxuid:* subject proves that the message came from a verified platform member. It does not automatically make that person a user of your commerce, CRM, or ERP system.

The business backend must map that subject to its own user and tenant, then apply the existing permission and resource checks. If no mapping exists, reject the action instead of promoting the platform member to an administrator.

Pre-production checklist

Bind the channel only to the intended route, client, and budget boundary.
Prevent duplicate platform deliveries from creating duplicate business effects.
Use asynchronous delivery after the short reply window instead of treating a platform timeout as a blind retry signal.
Keep final authorization in every business tool after the subject is restored.
Correlate the platform message, route, tool calls, and final delivery in the trace.