客户群运营的接口掰开就五个，串成一条线：建群 → 查人 → 拉人 → 管群 → 发消息。欢迎语和防骚扰规则是另一套配置接口，之前单独写过，这篇把群里"人和消息"的接口一次讲全。
建群：createGroup 拿到 roomId
resp = requests.post( f"{BASE}/wx-api/api/group/createGroup", headers=HEADERS, json={ "appid": APPID, "name": "产品售后-张先生专属群", "owner": owner_uin # 群主，int64 的 uin } ) room_id = resp.json()["data"]["roomId"] # int64，后面所有群操作都用它群名带上客户名和用途，员工找群不用翻。roomId是 int64，JSON number，加引号必报错——这个坑在群模块的出现频率比通讯录还高，因为 roomId 经常从 URL 或日志里复制出来，天然带引号。
自动化建群要节制：之前没加限制，系统一天自动建了十几个几乎一样的群，员工找哪个群都得搜半天。加一道去重——群名 + 成员哈希在 24 小时内建过就复用，不重复建。
查人和拉人：先看再动
# 拉成员列表，核对当前都有谁 requests.post(f"{BASE}/wx-api/api/group/getGroupMemberList", headers=HEADERS, json={"appid": APPID, "roomId": int(room_id)}) # 拉人进群 requests.post(f"{BASE}/wx-api/api/group/addGroupMember", headers=HEADERS, json={"appid": APPID, "roomId": int(room_id), "userIds": [uin1, uin2]}) # int64 数组先查后拉是个好习惯：拉人前核对一遍成员列表，避免把已经退群的人重复拉——重复拉人会触发异常返回，日志里全是噪音。
管群：公告和管理员
群运营的日常管理走updateGroup：改群公告、设置管理员。公告是群里触达率最高的位置——新成员进群第一眼看到的就是它，把群的规则和使用说明写在公告里，比发十条群消息都管用。管理员设置则决定了群主不在时谁能管事，售后群、项目群都建议配至少一个管理员。
发消息：sendText 换个目标就是群发
群消息和单聊走同一个message/sendText接口，区别只在conversationId传的是roomId：
import time rooms = [r["roomId"] for r in get_my_rooms()] for room_id in rooms: requests.post(f"{BASE}/wx-api/api/message/sendText", headers=HEADERS, json={ "appid": APPID, "conversationId": int(room_id), # 群聊传 roomId，必须 number "content": f"【产品更新】本周已上线 {feature}，详见群公告" }) time.sleep(3) # 群与群之间留间隔群发的节奏比内容更重要，三条纪律：
串行 + 间隔：同一个 appid 的发送串行进队列，群与群之间留几秒间隔，并发直推容易触发限流（返回 45009 或 -301002 就是在提醒你退避）
内容差异化：所有群发一模一样的文案，既容易被判定为营销骚扰，客户体验也差；按群打过的标签分组，不同组不同内容
节制频次：客户群不是推送管道，一天多条的群很快就没人说话了
一条线串起来
真实业务里这五个接口通常是这个组合：客户咨询触发createGroup建专属群 →addGroupMember把客户、销售、技术支持拉进来 →updateGroup写好公告 → 过程中用sendText推进度 → 结案后归档。把这条线跑通，客户群的"建管发"就闭环了。
接口路径、参数和事件回调的字段说明在 Eyun 开发文档里查，实例凭证在官网开通后即可调用。
