我用 wecomapi 这个开源项目把企业微信外部群批量邀请跑通了

2026/6/15 21:15:56

做私域的时候一直缺个能编程把人往客户群里拉的工具。痛点很具体：企业微信官方接口并没有开放「程序化批量邀请成员入群」这种能力，官方留给你的就是运营在手机上点「邀请」、一个一个手动加，几百人的量级根本扛不住，还容易漏。前阵子在 GitHub 上发现了 wecomapi 这个开源项目，主打给企业微信做二次开发、补外部群这块的能力，正好手上有个「新一期训练营批量拉学员进群」的需求，就拿它把官方做不到的「批量邀请成员」用 API 自动化跑通了。这篇记一下我的过程和踩到的坑。

邀请用哪个接口

翻了翻它的接口，往外部群拉人用的是 /room/inviteRoomMember。参数很直接：往哪个群拉（roomId）、用哪个账号去拉（guid）、拉哪些人（memberList，一个 userId 数组）。所谓「批量」，本质就是 memberList 一次塞多个——这正是手动操作给不了的效率。

我自部署后调用的请求体形如：

{"method": "/room/inviteRoomMember","params": {"guid": "<账号实例ID>","roomId": "<外部群ID>","memberList": ["wmUser_01", "wmUser_02", "wmUser_03", "wmUser_04"]}
}

完整一点的 curl，我是这么发的：

curl -X POST <网关地址>/api/qw/doApi \-H "<鉴权Token头>: <Token>" \-d '{"method":"/room/inviteRoomMember","params":{"guid":"<账号实例ID>","roomId":"<外部群ID>","memberList":["wmUser_01","wmUser_02"]}}'

别一股脑全灌进去

我实测时最先踩的坑就是「贪多」。一次塞太多，账号很快就被限。几点工程上的体会：

分批切片。我把上千人的大名单切成小批次提交，比如每批几十人，批次之间留点间隔，别让一个账号在极短时间内发出海量邀请——这种行为很容易触发平台风控。
先去重再提交。提交前把已经在群里的人剔掉。群里已有谁，我是先用 /room/batchGetRoomDetail 拉一次群详情，拿到当前成员列表做差集，避免重复邀请。
userId 要对得上账号。memberList 里的人必须是当前 guid 这个账号能触达的外部联系人，跨账号的 userId 拉不进来，这点我验证过确实进不去。

邀请是否成功，看回调

试下来一个重要结论：邀请发出去不等于人就进群了——对方可能没点确认，也可能群满了。真正「谁进群了」是通过 Webhook 事件回调告诉你的。成员成功加入会以系统事件推过来：

{"code": 0,"data": [{ "guid": "<账号实例ID>", "cmd": 15500, "fromRoomId": "<外部群ID>", "userId": "wmUser_01" }]
}

cmd=15500 是系统事件这一档，群成员加入、移出、群改名、解散都走它；fromRoomId 是发生事件的群。我的做法是把这条回调当作「邀请成功」的确认信号，回写进自己的入群状态表，比盲目相信调用返回值靠谱得多。

回调处理我记了两点：收到要在 3 秒内回 200；同一事件可能重复推送，按 seq 或 msgUniqueIdentifier 做幂等，别把一个人记成进群三次。

小结

官方接口没把「批量拉人入群」开放成可编程能力，这块基本只能靠人工手点。用这个开源项目 wecomapi 给企业微信做二次开发，正好把这件官方做不到的事补上：/room/inviteRoomMember 一次传多个 userId + 分批限速 + 用 cmd=15500 回调确认入群结果。我把「发起邀请」和「确认入群」拆成两个状态，整条流程才稳下来，也才好把入群结果回写进自己的运营系统。该能力仅用于客户服务、社群运营等正当场景，邀请频率请控制好，具体字段以官方接口文档为准。源码地址 github.com/wechat-ipad-api/wecomapi，感兴趣可以自己翻。