私域加粉链路上有三个经典断点客户扫码加了好友运营半小时后才点通过客户热情凉了通过之后没有欢迎语对话框一片空白加了五千个粉没人记得谁从哪个渠道来的。这篇把加粉链路做成全自动闭环识别好友请求 → 自动通过 → 秒级欢迎语 → 来源打标 → CRM 入库每一步都有接口依据。加粉链路全景客户发起好友请求 ↓ Webhook 回调(MsgType37)→ 自动通过 ↓ ↓ 秒级欢迎语(postText) 来源打标(label/modifyMemberList) ↓ 加粉成功事件(ModContacts)→ 写入 CRM整条链路里微信平台侧只负责推事件和执行动作来源记录、欢迎话术、客户分层全在你的业务系统——这正是自动化的意义。第一步识别好友请求MsgType37)好友请求在回调报文里的标识是MsgType37(WTAPI 回调文档 MsgType 编码表原文。请求者的信息在Content.string的结构化内容里defroute(data):msgdata.get(Data,{})# 先去重(官方键:Appid NewMsgId),再路由ifmsg.get(MsgType)37:handle_friend_request(data)elifdata.get(TypeName)ModContacts:handle_contact_added(data)注意好友请求也要走回调的两条硬约束3 秒内响应业务丢异步队列、Appid NewMsgId去重——重复推的好友请求如果处理两次会重复发欢迎语。第二步自动通过识别到 37 之后调官方文档「好友管理」模块的接受好友请求接口完成通过动作。这一环节的提醒接口参数以官方文档好友模块为准——通过动作通常要用到回调报文里Content.string解析出的请求信息照文档字段映射即可。通过是异步的接口返回成功不代表立刻加上真正的加粉成功信号是后面的ModContacts事件链路设计时别把两步当一步。不是来者不拒营销号、同行探子、广告号混在好友请求里是常态通过前先过一道黑名单和规则比如无验证消息的不通过否则欢迎语和标签全浪费在垃圾号上。第三步秒级欢迎语通过之后 3 秒内发欢迎语是加粉转化的黄金窗口——客户刚加你注意力还在对话框上。用postText三个参数搞定WELCOME欢迎添加~回复【资料】领取入门指南,回复【客服】找人工defsend_welcome(new_friend_wxid):returnrequests.post(f{BASE}/finder/v2/api/message/postText,headersHEADERS,json{appId:APP_ID,toWxid:new_friend_wxid,content:WELCOME},timeout10).json()欢迎语里埋指令钩子回复关键词领资料是标准打法客户的第一次回复会再次触发回调顺势进入关键词自动应答流程第一天就把互动跑起来。第四步来源打标加粉渠道哪个二维码、哪个活动、哪个销售必须在加粉瞬间记录事后补录基本等于丢失。打标用 WTAPI 标签接口两个配合label/list:body 只有{appId}返回data.labelList拿到渠道A对应的labelId;label/modifyMemberList给客户写入标签。最大的坑全量修改语义。官方文档明确强调labelIds传的是最终状态——客户已有标签 1、2新增标签 3 要传1,2,3只传3会把旧标签全部冲掉defadd_label(wxid,new_label_id):ownedget_owned_label_ids(wxid)# 查客户已有标签(CRM或缓存)ifnew_label_idinowned:returnowned.add(new_label_id)returnrequests.post(f{BASE}/finder/v2/api/label/modifyMemberList,headersHEADERS,json{appId:APP_ID,labelIds:,.join(map(str,owned)),# 全量传wxIds:[wxid]},# 数组timeout10).json()来源标签打好了渠道效果分析才有数据基础“渠道A加了 800 粉7 日留存 40%渠道B加了 2000 粉留存 5%”——投放钱往哪花一目了然。第五步加粉成功事件写 CRMModContacts事件联系人变更是加粉成功的确认信号。收到后把新客户资料同步进 CRMwxid、加粉时间、来源标签、分配的客服账号Appid)。至此链路闭环客户从发起请求到进入你的客户资产库全程无人值守。想先把好友请求回调和标签接口在线调一遍的WTAPI 开发文档weiti.apifox.cn支持在线调试——目前提供 7 天接口调用权限后台附带 Demo 示例可供本地调试。接口路径与字段以文档实时内容为准。风控红线自动通过不是免检通道加粉动作是平台风控的重点关照对象三条红线必须内化到代码里频次控制单位时间内通过数量要有上限瞬时大量通过是典型的机器行为特征。WTAPI 文档站有「运维与风控规范」专区红线写进调度器别靠自觉。分时段执行通过动作打散到全天别集中在凌晨批量处理白天积压的请求。账号质量是地基注册时长≥3 个月、已完成实名认证、使用官方客户端官方账号使用建议原文——用新号做自动加粉什么链路设计都救不了。上线节奏先单账号跑通37 识别 → 通过 → 欢迎语最小闭环观察一周通过后的留存和互动数据跑稳后再加来源打标和 CRM 同步最后按渠道铺量。加粉链路全自动之后运营的精力从点通过转移到优化欢迎语和渠道质量——这才是自动化该解放出来的时间。合规声明本文示例仅用于技术学习与合规私域自动化场景。自动通过好友、批量加粉等行为应严格遵守平台规范与频次要求使用注册 3 个月以上、已实名的合规账号不得用于骚扰、欺诈等违规场景。