← 所有文章
指南

WhatsApp BSUID 遷移 7 月 7 日啟動——入站團隊的五項檢查清單 — UnifyPort

Meta 正在改變 WhatsApp API 中識別使用者的方式。從 2026 年 7 月 7 日（第一波）開始，每個 webhook 酬載中都會出現一個名為 Business-Scoped User ID（BSUID）的新欄位——而對於啟用 WhatsApp 使用者名稱的用戶，手機號碼可能會完全消失。

如果你的客服佇列、CRM 整合或 AI 代理流程中會接收 WhatsApp 訊息，這次遷移會影響到你的程式碼。影響程度取決於你的 WhatsApp 訊息在抵達後端之前經過了哪條路徑。

這篇文章是一份檢查清單。五個需要檢視的領域、一個決策矩陣，以及大多數小型團隊真正想問的問題的明確答案：「7 月 7 日之前我需要做什麼嗎？」

BSUID 到底是什麼

每個 WhatsApp 使用者都會獲得一個新的識別碼：Business-Scoped User ID。格式為兩個字母的國碼、一個點號，加上最多 128 個英數字元——例如 BR.1A2B3C4D5E6F7G8H9I0J。關鍵特性：同一個人與不同企業互動時，會得到不同的 BSUID。你的系統為使用者 Alice 產生的 BSUID，跟另一家公司的 BSUID 完全不同。

Meta 的部署時程：

階段日期範圍
第一波2026 年 7 月 7 日初始市場
第二波2026 年 7 月 20 日擴大部署
全球2026 年 9 月其餘所有市場

BSUID 自 2026 年 3 月 31 日起已經開始以新的 user_id 欄位出現在 webhook 酬載中。但真正的破壞性變更在第一波：一旦使用者啟用了 WhatsApp 使用者名稱，wa_id 和 from 欄位中的手機號碼可能就不再出現。

檢查清單：五個需要檢視的領域

1. Webhook 酬載解析

變更內容： 每個訊息 webhook 都會新增一個 user_id 欄位。對於啟用使用者名稱的用戶，原本包含手機號碼的 wa_id 和 from 欄位可能會改為 BSUID——或完全缺失。

檢查重點： 你的 webhook 處理程式是否假設 from 一定是手機號碼？是否用正規表達式比對數字、將其作為資料庫主鍵，或傳給電話號碼驗證函式庫？當 from 的值從 5511999887766 變成 BR.1A2B3C4D5E... 時，上述做法都會出錯。

2. CRM 與聯絡人比對

變更內容： 如果你的 CRM 以手機號碼作為客戶記錄的主鍵，來自啟用使用者名稱的用戶的訊息可能完全不含手機號碼，你將無法查找到該客戶。

檢查重點： 你的聯絡人資料庫能否同時儲存並比對 BSUID 和手機號碼？Meta 提供了 Contact Book API 來保留先前對話中的號碼與 BSUID 對應關係——但你需要在手機號碼從新 webhook 中消失之前就呼叫過它。

3. 對話歷史與訊息串接

變更內容： 如果你按手機號碼串接對話（例如「顯示 +5511999887766 的所有訊息」），同一個人的訊息將開始以 BSUID 識別碼出現。除非你已將舊的號碼記錄與新的 BSUID 建立關聯，否則對話歷史會一分為二。

檢查重點： 你的訊息儲存系統是否以手機號碼作為對話串的主鍵？如果是，請規劃一次回填作業：在第一波之前，使用 Contact Book 的對應關係，將現有的號碼記錄與 BSUID 連結起來。

4. 範本與外發訊息定址

變更內容： 發送範本訊息（外發）時，你最終需要以 BSUID 而非手機號碼來定址收件人——特別是那些已啟用使用者名稱、手機號碼不再公開的用戶。

檢查重點： 如果你會主動發送訊息（訂單確認、出貨通知、預約提醒），你的發送邏輯是否以手機號碼解析收件人？你需要儲存最近一次入站訊息中的 BSUID，並在未來的外發呼叫中使用它。

5. 資料儲存與合規

變更內容： BSUID 是一種新的個人可識別資料。雖然它按企業區隔（因此無法用來跨公司交叉比對使用者），但在大多數隱私法規框架下仍屬於個資。

檢查重點： 你的資料保留政策是否涵蓋新的識別碼類型？如果你有 GDPR/PDPA 的刪除流程會列舉使用者的所有已儲存識別碼，BSUID 也需要納入。

你走的是哪條路？

並非每個團隊都需要處理全部五項檢查。這取決於 WhatsApp 訊息如何抵達你的後端。

整合路徑適用的檢查項目遷移工作量
Cloud API（直接串接）全部五項高——你直接解析 Meta 的原始 webhook，每個酬載變更都會直接影響你的程式碼
BSP（Wati、360dialog 等）第 2、3、4、5 項中等——你的 BSP 可能會抽象化 webhook 格式，但 CRM 和發送邏輯仍需更新
非官方入站介面無零——繼續往下看

為什麼非官方入站不受影響

如果你的 WhatsApp 訊息是透過 UnifyPort 的非官方介面接收的，BSUID 遷移完全不會觸及你的流程。原因很簡單：UnifyPort 不透過 Meta 的 Cloud API 傳遞訊息。非官方路徑直接連接 WhatsApp——就像一支執行 WhatsApp 的手機一樣——因此你的 webhook 收到的訊息從一開始就不是 Cloud API 的酬載格式。

你的 webhook 仍然收到與以往完全相同的 message.received 事件：

{
  "event": "message.received",
  "account_id": "acct_3qPmRz",
  "provider": "whatsapp",
  "from": "user_88c1ae",
  "text": "Hi, is order #2241 shipped yet?",
  "timestamp": 1751875200,
  "message_id": "wa_msg_f4e29a"
}

from 欄位是 UnifyPort 自有的正規化使用者識別碼——不是手機號碼，也不是 BSUID。它從來就不是手機號碼，所以當 Meta 變更識別碼機制時，你不需要進行任何遷移。你的 CRM 比對、對話串接和 webhook 解析全部照常運作。

webhook 端點上的 HMAC-SHA256 簽章驗證同樣不受影響——簽章密鑰和格式都是 UnifyPort 的，不是 Meta 的。

本週該做什麼

如果你使用 Cloud API 或 BSP：從檢查項目 1（webhook 解析）開始。記錄一批近期的入站 webhook，檢查 user_id 欄位是否已經出現——它從 3 月 31 日起就已陸續上線。如果已經存在，代表你的酬載已經在變化中。在 7 月 7 日之前完成第 2 到 5 項。

如果你使用非官方入站路徑：什麼都不用變。BSUID 遷移是 Cloud API 層面的事，你的訊息不經過 Cloud API。繼續開發就好。