内部群配一个 Webhook，文本可以秒到。同一套机器人往外部群、客户群里加，要么没有添加入口，要么发出去的人看不见。合同写「群机器人」，验收却拿客户群，能力边界从签字那天就对不上。双方后来会争「上午还能用」，其实上午演示的根本不是那条路。

两条通道的执行主体不同

内部群机器人以机器人身份说话，走群 Webhook，适合组织内通报。外部群通常没有这个席位。官方那套群机器人加不进去。能走的路径是：已经在这个群里的员工账号，按会话标识做消息投递。风控、话术、频率都按真人口径，不能按机器人通报的密度去打。

因此外部群通知的链是：业务事件 → 系统判定发不发、发给哪个群 → 指定员工节点和 roomId 投递 → 成员在该员工会话里看见。不存在「一个 Webhook 覆盖全部客户群」这种隐含能力。每一个外部群都是一个接收方。员工被移出后再调用，失败域是对象失效。继续改文案没有用。

toId 在群场景填 roomId，在联系人场景填 userId。填反则可见性出现在另一类会话：内部群有声，客户群无记录。回执如果没有会话类型，值班无法陈述「发到了哪一类屋子」，业务侧会按未送达再投一次，变成双写。

外部群投递仍走统一入口，只是 toId 必须是群。会话类型要跟调用一起记下：

# 文档字段：method / guid / toId / content
body = {
    "method": "/msg/sendText",
    "params": {
        "guid": guid,
        "toId": room_id,  # 外部群用 roomId，不要填好友 userId
        "content": text,
    },
}
# 本地审计，不是请求字段
audit = {"session_type": "external_room", "to_id": room_id}

请求体里没有「这是外部群」这种开关，类型是你自己的记账。Webhook 推内部群成功，不能拿这段 room_id 去顶替。员工不在该群，对象域失败，继续改 content 没有用。

排障顺序是屋子，不是签名

内部通、外部不通，优先核对回执里的群类型，再核对这个员工是否还在目标外部群，再核对是不是把内部 Webhook 的成功误当成外部群已通。外部群对短链、二维码更敏感，内容策略也可能单独拦截。改三天签名，人还是不会出现在客户群该出现的位置。

依赖当前前台窗口的点击脚本更糟。焦点在内部群，任务却按外部群记账。投递必须以会话标识为准，不依赖聊天窗口是否在前台。

演示和上线必须用同一类群。验收现场用内部群，上线才拿外部群，能力对不上。内部群绿灯不能写入外部群验收项。固定一个只有内部成员的外部测试群，第一条标准是这个群里肉眼看到该出现的那一句，而不是内部群又响了一声。

查看企业微信 API 文档：
https://doc.qiweapi.com/