WhatsApp Embedded Signup 完成后如何验收：后端核对清单
WhatsApp Embedded Signup 弹窗显示完成，只能证明前端流程走到了终点，不能证明租户已经可用。后端还应关联本次会话、验证 token、匹配正确的 WhatsApp Business Account（WABA）、核对系统用户权限、确认号码路径、订阅 WABA，并让一条真实 webhook 通过租户路由与验签。每一项都应是独立验收门槛。
核心结论
FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING表示 Coexistence 弹窗完成，不代表后端接入全部成功。- Meta 官方 Embedded Signup collection 要求继续获取共享 WABA、配置系统用户、按适用路径注册号码，并订阅 WABA webhook。
- 不要默认使用列表中的第一个 WABA；必须与当前租户和业务资产精确匹配。
- 信用额度绑定只适用于由合作伙伴代付的计费模式，不是所有接入的通用门槛。
- 最终可用信号是一条真实事件进入正确租户，并完成校验、去重和确认响应。
WhatsApp Embedded Signup 完成后的验收清单
Meta 的官方 Embedded Signup collection把浏览器流程与 Graph API 后续步骤分开：获取共享 WABA、添加或核对系统用户、注册号码、订阅应用，以及在合作伙伴承担账单时共享信用额度。
这与已有的 Embedded Signup v4 迁移清单意图不同。迁移清单解决“如何迁移启动配置并保留 Coexistence”；本文从完成事件之后开始，回答后端要保存哪些证据，才能显示“已连接”。
| 门槛 | 应保存的证据 | 未通过时的风险 |
|---|---|---|
| 会话关联 | 租户 ID、一次性 state、configuration ID、完成时间 | 正确结果可能绑定到错误租户 |
| Token 验证 | app、权限范围、有效期元数据 | 有 token，但无权管理目标 WABA |
| WABA 匹配 | 与业务上下文一致的准确 WABA ID | 列表第一项可能属于其他客户 |
| 系统用户 | 被授权的 system user 与所需 task | 弹窗完成，但后续 Graph API 失败 |
| 号码就绪 | phone-number ID 与注册或 Coexistence 状态 | 拿到 WABA，但消息能力未就绪 |
| 应用订阅 | WABA 出现在 subscribed_apps | Meta 收到消息，但 webhook 不投递 |
| 真实投递 | 事件、租户路由、校验与确认结果 | 只有配置证据，没有端到端证据 |
按顺序实施七个门槛
1. 用服务端会话关联前端结果
打开 Meta 弹窗前，由服务端创建一次性会话，记录租户、操作者、configuration ID 和接入路径。完成结果只接受一次；state 过期或不匹配时拒绝处理。Token 不能进入浏览器日志、埋点或错误上报。
Coexistence 路径应记录官方定义的 FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING。其他 Embedded Signup 路径按其当前官方完成契约处理，不要仅凭显示文案或一个版本数字统一分流。
2. 先验证 token，再使用资产 ID
通过 Meta 的 token debugging 流程确认 token 属于你的 app，并包含接入所需权限。非空 token 不等于授权成功。服务端只持久化审计与续期所需的最少元数据，不要把 token 原文写入日志。
3. 确定性匹配目标 WABA
读取当前 business 可访问的 shared/client WABA，再用本次会话记录的业务上下文匹配准确 WABA ID。多租户系统不得依赖数组顺序。没有精确匹配时，保留为可恢复的 verification_required，不要静默绑定其他资产。
4. 核对系统用户和号码路径
官方 collection 提供 GET /{waba-id}/assigned_users 来验证目标 system user 的权限。还要核对后端实际需要的 task，不能把“存在任意授权”当成通过。
随后按接入类型分支：标准 Cloud API 可能需要注册号码；Coexistence 使用已连接 WhatsApp Business app 的号码，应验证其当前状态，而不是重复注册。是否确实需要这一官方双端模式，可先阅读 Coexistence 决策指南。
5. 订阅 WABA 并证明真实投递
用服务端凭据调用 POST /{waba-id}/subscribed_apps，并再次读取验证。订阅状态与号码状态必须分开保存，因为它们可能各自成功或失败。
最后通过一条受控测试消息，让真实 webhook 完成租户查找、载荷校验、去重和确认响应。若接收端使用 UnifyPort，可按 webhook 投递与签名校验核对原始请求体、X-Device-Timestamp、X-Device-Signature 与 endpoint 的 signing_secret。
UnifyPort 的承接边界
UnifyPort 不会完成 Meta Embedded Signup，也不会分配 WABA 权限、注册 Cloud API 号码、绑定信用额度或保留 Coexistence。Solution Partner 或 Tech Provider 需要这些官方资产时，应使用官方流程。
UnifyPort 的范围更窄：连接普通 WhatsApp 账号，并把支持的入站消息标准化为 message.received。如果真实需求是入站队列，而不是为客户配置 WABA，可先比较三种 WhatsApp 入站路径，再查看 WhatsApp 授权指南。
限制与取舍
这份清单不能证明 Meta 商家资格、App Review、显示名称审批、号码质量或政策合规；这些是独立的平台状态。测试租户通过也不等于所有客户配置都可用。
非官方接口不能授予 Cloud API 官方资产，也不能代替多租户 SaaS 所需的 Embedded Signup。反过来，弹窗完成也不能证明租户映射、重试、webhook 接收器或计费边界正确。应把“前端完成”和“运营可用”设计成两个状态。
FAQ
FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING 表示什么？
它表示 WhatsApp Business app onboarding 弹窗到达官方定义的完成状态；后端仍需验证会话、资产、权限、订阅和真实投递。
拿到 Embedded Signup token 就能标记客户已连接吗？
不能。还要验证 token，并匹配准确 WABA、系统用户、号码路径和 webhook 订阅。
所有接入都必须绑定信用额度吗？
不是。只有合作伙伴代付 Meta 账单并向客户结算时，才需要相应的信用额度步骤。
Coexistence 号码需要再次注册吗？
不需要。它已经通过 WhatsApp Business app 连接，应验证官方定义的状态和同步路径，而不是重复标准号码注册。
最终验收信号是什么？
至少一条受控 webhook 进入正确租户，并由接近生产环境的接收器完成校验与确认。
下一步
先按 Meta 官方 Embedded Signup collection实现这些门槛，再开放租户。如果只需要普通账号入站，可评估独立的 UnifyPort WhatsApp 授权路径。
来源
官方来源核验日期：2026-08-05。