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；必須與目前租戶及商業資產精確匹配。
- 信用額度綁定只適用於合作夥伴代付模式，不是所有接入的共同門檻。
- 真正的可用訊號是一筆事件進入正確租戶並完成驗證、去重與回應。
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 出現在 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 投遞與簽章驗證核對原始 request body、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 號碼需要再次註冊嗎？
不需要。應驗證官方定義的狀態與同步路徑，而不是重複標準號碼註冊。
最終驗收訊號是什麼？
至少一筆受控 webhook 進入正確租戶，並由接近正式環境的接收器完成驗證與回應。
下一步
先依 Meta 官方 Embedded Signup collection實作門檻，再開放租戶。若只需要一般帳號入站，可評估 UnifyPort WhatsApp 授權路徑。
來源
官方來源核驗日期：2026-08-05。