企业微信 iPad 协议是什么

这个说法是怎么来的

在个人微信生态里，很早就有按客户端类型区分接入方式的习惯 —— 手机端、PC 端、iPad 端各自的登录席位和能力范围不同，于是「iPad 协议」被用来指代一类以独立席位登录、功能相对完整的接入方式。企业微信兴起之后，这套说法被顺手搬了过来。

所以你在搜索结果里看到的「企业微信 iPad 协议」，多数时候表达的是同一个诉求：我不想让员工手动操作，我想让自己的系统直接收发消息、管理客户和外部群。至于底层究竟怎么实现，不同服务商差别很大，这个词本身并不说明任何技术细节。

从个人微信搬过来，丢掉的是企业这一层

这个说法的麻烦不只是不准确，还在于它把个人微信生态的心智一起带了过来。个人微信里，账号和用它的人基本是同一个东西；企业微信不是 —— 账号是企业的一个成员席位，由管理员在后台增减，人走了席位还在。这一层差别不写在任何一份接口说明里，却会直接改写你的数据模型。

• 账号标识和「现在谁在用这个账号」必须是两个字段。合成一个的系统，第一次人员变动就要回头改历史数据，而那时候这些数据已经和客户关系绑在一起了。
• 客户归属由企业侧的管理规则决定，不由你的程序决定。自动跟进的逻辑要能接受「这批客户明天换个人负责」，而不是把负责人写死在业务表里。
• 程序发出的消息和人发的消息落在同一个企业视角下。按「这条消息将来会被人翻出来看」的前提写代码，比事后解释便宜得多。

第一条看起来只是个建模细节，实际是这三条里唯一会随时间变贵的。第一天把两者合成一个字段，省下的是几行代码；等到第一次交接发生，要跟着改的是历史消息、跟进记录，以及一切按「人」聚合过的统计。自查方法很简单：在你的表里找一找，有没有一个地方能表达「同一个账号换了人」—— 找不到，说明这套模型只适用于人员不流动的公司。

官方开放平台是另一条路线

企业微信有完整的官方开放平台：企业在管理后台创建应用、配置可见范围与权限，之后用 access_token 调用官方接口。这条路线的特点是规范公开、边界明确、适合以官方应用形态上架和分发。

它的成本主要在前置环节：能力范围由企业管理员的授权决定，接入前需要完成一系列后台配置；不同能力对应不同的权限项，跨企业分发还涉及第三方应用的审核流程。对于「先跑通一条链路验证想法」的团队，这段前置往往比写代码更耗时间。

• 官方开放平台：规范公开、可上架分发，前置配置与授权较重
• 网关式接入：把账号托管起来对外暴露统一 REST 接口，接入快、编排集中
• 两者不互斥 —— 官方规范能满足的用官方，需要统一编排与联调效率的走网关

网关式接入具体怎么接

以 wecomapi 的做法为例：账号实例托管在网关侧，登录态维持、心跳保活与异常自愈都收敛在平台内部，对外只暴露一套统一的 REST 接口与 Webhook 事件回调。消息收发、客户与好友、外部群、事件订阅用的是同一套请求结构、同一套鉴权与错误模型。

curl -X POST https://manager.wecomapi.com/message/sendText \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "guid":    "7db8...",
    "toId":    "78813...",
    "content": "Hello WeCom"
  }'

对使用方来说，这意味着不需要为每种能力对接不同的接口形态，也不需要自己维护接入环境。精确的字段定义、错误码与端点以 wecomapi 线上接口文档为准 —— 能力覆盖面会随版本变化，文档是唯一可信来源。

预算的变量是账号数，不是消息量

两条路线的成本结构不一样，这一点在选型表上常被挤进同一栏。官方路线的开销主要在前置：创建应用、申请权限、跨企业分发时的审核，都是人天，一次性但很难压缩，而且这段时间多半不由你控制。网关路线的开销是订阅，变量只有账号数和周期两个。

所以定价形态要在选型阶段就问清楚：是按账号订阅，还是按调用次数计。wecomapi 属于前者 —— 按账号订阅，订阅内可无限次调用接口、不按调用次数计费（适用公平使用策略）。按账号订阅的价值不在单价便宜，而在预算表里要填的那个数换了一个：从「一天发多少条消息」变成「半年后有几个账号在跑」。后一个数业务侧提前给得出来，前一个数在上线前基本靠猜。

• 非生产账号最常被漏掉。联调和预发各要占一个，不算进预算的结果通常是拿生产账号做测试 —— 省下的那点订阅费，第一次误发就赔回去了。
• 按业务线拆出来的账号要单独算。售前、售后、社群共用一个账号在管理上本来就不合适，这个拆分是业务决定，但账单是按拆完之后的数量出的。
• 波动要提前问。活动期多开几个账号跑一个月再停，这类需求在立项时就要确认能不能按月增减，而不是等到活动前一周才发现要重新谈。

反过来，如果评估的方案按调用次数计价，预算表上要多留一栏：为了正确性而产生的那部分调用 —— 重试、状态巡检、定时对账。它们通常比业务调用本身还多，而且系统做得越规范就越多。漏掉这一栏，是接入几个月后账单和预估对不上的常见原因。

选型时该问的四个问题

1. 1目标形态是什么：要以官方应用上架分发，还是把能力接进自有系统？前者优先官方开放平台。
2. 2需要的能力和字段在不在覆盖范围内？别看宣传口径，直接对着文档逐项核，并在预发环境实测。
3. 3数据怎么流转、留在哪里、谁能访问？这条决定了方案能不能过你们自己的合规评审。
4. 4出问题时能不能定位？有没有统一错误码、请求标识和调用日志，直接决定联调和线上排障的成本。

这四个问题的顺序不能换。第一条是唯一一个答案在你自己手上的 —— 目标形态没定就去问后面三条，对方的方案会顺手替你把目标定了，而且多半定成他最擅长的那一种。先在内部把第一条答完，后面三条问出来的答案才有淘汰的效力。