获客系统里最常见的自动化诉求：拿到一批手机号，让企微账号逐个发起好友申请。企微接口里这不是一个接口的事，而是"先搜索拿票据、再凭票据发起申请"的两步链路。这篇把这条链路拆开讲，重点说票据的有效性管理和申请节奏控制。

背景痛点

很多团队的第一版实现是拿到手机号直接调加好友接口，结果全部失败。原因在于加好友的前提是先确认这个手机号能定位到一个企微或微信用户，这一步产出的票据才是申请的入场券。两步链路里的状态管理，比接口调用本身更值得设计。

原理

链路的第一步是手机号搜索：按手机号查询用户，拿到添加好友所需的票据 wxTicket，以及对方的身份信息 openid、uin、corpId。第二步才是发起申请：个人微信用户和企微用户分别对应两个接口，都用第一步的票据。用户资料还能通过用户详情接口按 ID 直接查，内部成员和外部联系人都支持。

这条链路的定位要说明白：它解决的是"有明确手机号线索"的获客场景，每一笔申请仍然以账号本人身份发出，频率限制与企微官方规则一致，不存在绕开审核的用法。

核心实现

两步链路串起来（示例代码，需按官方文档校验，字段名以接口页为准）：

def add_friend_by_phone(appid: str, phone: str):
    # 示例代码，需按官方文档校验
    found = api("/wx-api/api/contact/phoneNumberSearch",
                {"appid": appid, "phone": phone})     # 搜索拿票据与身份
    ticket = found["data"]["wxTicket"]
    return api("/wx-api/api/contact/phoneNumberAddWechat",
               {"appid": appid,
                "wxTicket": ticket,                    # 凭票据发起申请
                "greeting": "您好，我是您的专属顾问"})  # 其余字段见接口页

对方是企微用户时，换用通过手机号添加企微的接口，身份字段用搜索返回的企微侧信息。搜索接口的参数与返回结构见Eyun 企微API开发文档，两个申请接口的字段见Eyun 平台对应的接口页。

踩坑

一、票据有时效，搜索和申请要在一个短流程里完成，不要批量搜索完囤一堆票据再慢慢申请。票据失效的报错会伪装成"申请失败"，先查时效再查参数。

二、搜索结果要落库：手机号、对方身份 ID、申请时间、申请结果分开存。重复申请同一个手机号既浪费票据又是账号风险行为，申请前去重表里拦一道。

三、节奏控制放在申请侧而不是搜索侧：逐条发送、随机间隔、单日限量，把频率限制当成硬约束来设计，账号安全永远排在转化率前面。

四、申请通过后，新好友不会自己出现在本地库，订阅好友新增事件再触发同步，客户资料才算闭环。

总结

这条链路的工程要点可以压缩成三个词：票据短流程、申请去重、节奏限量。它适合 CRM 获客、老客户召回这类有明确线索来源的场景。这篇基于 Eyun 平台的企微接口整理，申请话术与频率的合规边界以企微官方规则为准，接口细节以开发文档为准。