← 所有文章
指南

WhatsApp 帳號模型演進：2026 年 WAAC 與 Messaging Account 拆分代表什麼

Meta 的 WhatsApp 帳號模型演進（Account Model Evolution）把舊版單一的 WhatsApp Business Account（WABA）拆成兩層：一層是持有身份與號碼的 WhatsApp Account（WAAC），另一層是持有訊息範本、計費與 Webhook 訂閱的 Messaging Account。實際影響是：一個號碼現在可以跨多個 partner 或直連 API 整合共享，而範本、吞吐量與計費則依 Messaging Account 各自隔離——同時，一個已淘汰的 API 參數必須在 2026 年 12 月 31 日前完成遷移。

重點結論

  • 舊版 WABA 正被拆成 WAAC（號碼、商家資料、使用者名稱、目錄）與 Messaging Account（範本、計費、Webhook 訂閱）——兩個職責不同的容器。
  • 一個號碼現在可以跨多個 partner 或直連 API 整合共享，但號碼的吞吐量是「共享」而非「疊加」。
  • 訊息範本不跨 Messaging Account 共享；每個 partner 或整合都要各自重建並重新送審。
  • 號碼的品質評級（quality rating）跟著號碼（WAAC）走，不跟著 partner 走，所以更換 BSP 不會重置信譽。
  • 整體遷移分三個階段推進到 2028 年，而已淘汰的 paid_messaging_account_id 參數必須在 2026 年 12 月 31 日前遷移到 messaging_account_id。

WhatsApp 帳號模型演進改變了什麼

在 Cloud API 的大部分生命週期裡，一個 WABA 包攬一切：號碼、商家身份、訊息範本、Webhook 訂閱、計費。Meta 的帳號模型演進把這個單一容器拆成兩層，讓身份與訊息營運可以獨立擴展。

新的拆分如下：

層級持有什麼拆分的意義
WhatsApp Account（WAAC）號碼、商家使用者名稱、商家資料、商品目錄即使訊息營運方更換，身份與號碼也保持穩定
Messaging Account（沿用舊 WABA ID）訊息範本、計費與付款方式、Webhook 訂閱範本、計費與投遞設定被限定在某一個營運方的整合內

影響最大的是號碼層面的變化。Meta 現在明確表示「客戶與直連開發者可以將其號碼共享給多個 partner」，並把結果描述為「一個受信任的號碼在所有整合中通用」。在舊模型下，一個號碼實際上綁定在一個 BSP 或一個直連 Cloud API 整合上，Meta 當時的文件寫的是「一個 WABA 最多可與兩個 partner 共享」。新架構把它泛化了，所以這是一次架構級的變更，而不是換個標籤。

這與 2026 年 10 月 1 日的計費變更相互獨立。服務訊息與工具訊息分類與服務訊息計費追蹤指南講的是「什麼訊息要收費、如何計量」。帳號模型演進講的是「號碼與範本歸誰所有」，而不是「每則訊息收多少錢」。

一個號碼多 partner 共享時，什麼共享、什麼隔離

「共享號碼」這個說法最容易讓人誤解成「什麼都共享」。官方文件劃了三條清楚的邊界。

吞吐量是共享，不是疊加

Meta 明確表示「當多個 partner 共享一個號碼時，他們共享該號碼的吞吐量上限」。一個有某則訊息／秒限額的號碼，不會因為 N 個 partner 在發送就變成 N 倍限額；各方從一個池子裡抽取。請依號碼層級規劃容量，而不是依 partner 層級。通用吞吐量文件定義了這個共享池所基於的每號碼預設值與自動升級級距。

範本不跨 Messaging Account 共享

Meta 明確表示「範本屬於建立它的那個 Messaging Account，不跨 Messaging Account 共享」。如果三個 partner 都要在同一個號碼上用訂單確認範本，每個 Messaging Account 各自保留一份副本，各自獨立通過 Meta 的範本審核。目前每個帳號 250 個範本的上限是依 Messaging Account 算的，不是依號碼算的。

品質評級跟著號碼走

一個號碼的品質評級（綠、黃、紅，基於使用者的封鎖與檢舉）是號碼——也就是 WAAC——的屬性，而不是營運該號碼的 partner 的屬性。這是一把雙面刃：一個狀態良好的號碼會把好信譽帶到所有 partner；而一個 partner 因發送行為不當把號碼做差了，會影響所有共享該號碼的 partner。請在各 partner 之間協調發送紀律，別假設各方的信譽是隔離的。

2026-2028 遷移時間線

Meta 把遷移分成三個階段，每個階段都在收緊開發者必須做的改動。

階段時間窗口發生什麼你必須做什麼
階段 1 — 正式可用2026 下半年Meta 自動處理帳號遷移，分離 WAAC 與 Messaging Account對大多數多帳號設定無需改程式；在後台核對拆分結果
階段 2 — 新版 Graph API2027 上半年最新版 Messages API 要求傳 messaging_account_id把指向 Messaging Account 的 API 呼叫更新為傳新識別碼
階段 3 — 強制遷移2028 上半年所有指向 phone number ID 的 API 必須改用 WAAC ID把任何基於 phone number ID 的路由遷移到 WAAC ID

階段 1 內部還藏著一個更緊的截止日。Meta 表示開發者必須「在 2026 年 12 月 31 日前遷移到 messaging_account_id，之後 paid_messaging_account_id 計畫被移除」。如果你的整合仍在傳送已淘汰的 paid_messaging_account_id 參數，請把這個日期當作硬切換點，而不是等階段 2 的窗口。

給 Solution Partner 與 Tech Provider 的遷移清單

這次遷移屬於擁有 Cloud API 整合的 partner 或 provider，不屬於只使用 WhatsApp Business App 的商家。如果你維護這樣的整合，請在每個階段切換前過一遍這份清單。

  1. 盤點所有提及 WABA、phone number ID 或 paid_messaging_account_id 的 API 呼叫。 一個共用的啟動器或共用設定可能藏著一個已淘汰參數，直到某個階段切換時才報錯。
  2. 在後台確認 WAAC / Messaging Account 的拆分結果。 核對階段 1 自動遷移後，哪些範本、Webhook 訂閱與計費方式落在哪個 Messaging Account 裡。
  3. 在 2026 年 12 月 31 日前把 paid_messaging_account_id 遷移到 messaging_account_id。 不要等階段 2；這個參數的移除有獨立的截止日。
  4. 依 Messaging Account 核對範本歸屬。 如果多個 partner 要在共享號碼上用同一個範本，在每個 Messaging Account 裡各自重建並重新送審，別假設會繼承。
  5. 對共享號碼依號碼層級建模吞吐量。 把共享該號碼所有 partner 的預期發送速率相加，確認落在號碼的共享容量內。
  6. 把品質評級的協調寫進文件。 因為評級跟著號碼走，所以要與每個共享 partner 就發送量與使用者同意（opt-in）紀律達成一致。
  7. 為階段 3 的 WAAC ID 切換準備好基於 phone number ID 的路由。 給所有依 phone number ID 路由的程式碼路徑打上標記，讓 2028 上半年的切換是一次受控遷移，而不是意外。

對於還在決定是否需要官方 Cloud API 路徑的團隊，接收 WhatsApp 入站訊息的三條路徑與BSP 平台比較會在你投入帳號架構遷移前框定這個決策。WhatsApp Coexistence 指南則覆蓋了在同一個號碼上同時跑 Business App 與 Cloud API 的相關問題。

UnifyPort 的位置

UnifyPort 不在 Meta 的帳號模型演進之內運作。它不管理 WAAC、Messaging Account、Meta 範本審核、Cloud API 權限或 Meta 計費。如果你的產品需要一個號碼跨多個官方 partner 共享，或需要在截止日前遷移 paid_messaging_account_id，那麼官方 Cloud API 路徑才是正確的，而且這次遷移對整合方是強制的。

UnifyPort 對接的是另一種需求：連結一個普通的 WhatsApp 帳號，把支援的入站訊息作為一條標準化的事件流接收下來。一則 WhatsApp 入站訊息以標準的 message.received 事件到達，與 Telegram、LINE、TikTok、Zalo、X 用的是同一個信封：

{
  "id": "evt_7c41f0b2a9",
  "type": "message.received",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-31T09:24:18Z",
  "data": {
    "conversation": { "id": "84901234567", "type": "user" },
    "sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "wamid.HBgM",
      "type": "text",
      "text": "Can your team check my shipment before closing today?",
      "direction": "inbound",
      "sent_at": "2026-07-31T09:24:16Z"
    }
  }
}

當 Webhook 端點設定了 signing_secret 時，每次投遞都會帶上 X-Device-Timestamp 與 X-Device-Signature，你的接收方在處理前要針對原始請求體驗證 HMAC-SHA256 簽章——詳見 Webhook 投遞與簽章參考。支援的回覆走 POST /v1/messages。

這條路徑與官方帳號架構是刻意分開的。它不授予 WAAC 身份、Meta 範本審核、Cloud API 權限，也不提供帳號模型演進所治理的任何多 partner 特權。請把兩條路徑分清楚：官方遷移改變的是號碼與範本在 Meta 平台內的歸屬方式；非官方入站介面改變的是普通帳號的訊息落在你系統的什麼位置。

限制與權衡

當你需要已審核的出站範本、官方行銷工具、Click-to-WhatsApp 歸因、Meta 原生分析、一個跨多個認證 partner 共享的號碼，或 BSP 代管的合規工作流程時，請使用官方 Cloud API 並完成帳號模型演進遷移。WAAC / Messaging Account 的拆分正是為了讓這些官方工作流程更清晰。

非官方介面無法提供上述任何 Meta 平台特權。它無法讓一個號碼在 Meta 模型下獲得多 partner 共享資格，無法審核範本，也無法遷移一個 Messaging Account 的計費與 Webhook。它更窄的價值在於：為普通訊息帳號提供標準入站介面，並跨多個平台提供一條標準化佇列——這與「如何結構化一個 Cloud API 整合」是不同的決策。

各階段日期（2026 下半年、2027 上半年、2028 上半年）與 2026 年 12 月 31 日的參數截止日都具有時效性。請在每次切換前複查 Meta 官方的帳號模型演進頁面，因為 Meta 會把這些文件向前滾動更新，且不帶可見的版本戳記。

常見問題

什麼是 WhatsApp 帳號模型演進？

它是 Meta 把舊版 WABA 拆成 WAAC（持有號碼與商家身份）與 Messaging Account（持有範本、計費與 Webhook 訂閱）的變更，使一個號碼可以跨多個 partner 或直連整合共享。

現在一個 WhatsApp 號碼能跨多個 BSP 共享嗎？

能。Meta 表示客戶與直連開發者可以把號碼共享給多個 partner。號碼的吞吐量在各方之間共享，每個 partner 的範本各自留在自己的 Messaging Account 裡。

訊息範本會跨 Messaging Account 共享嗎？

不會。Meta 明確表示範本屬於建立它的那個 Messaging Account，不跨 Messaging Account 共享。每個 partner 都要各自重建並重新送審所需的範本。

什麼時候必須遷移 paid_messaging_account_id？

Meta 表示開發者必須在 2026 年 12 月 31 日前遷移到 messaging_account_id，之後 paid_messaging_account_id 計畫被移除。

更換 BSP 會重置 WhatsApp 號碼的品質評級嗎？

不會。品質評級跟著號碼（WAAC）走，不跟著 partner 走。一個號碼的信譽會跨 partner 帶過去，好壞都一樣，所以發送紀律必須由所有共享該號碼的各方一起協調。

下一步

如果你擁有一個 Cloud API 整合，請從官方帳號模型演進指南開始遷移，並在 2026 年 12 月 31 日前停用 paid_messaging_account_id。如果你的需求是普通帳號的入站訊息，請先查閱 WhatsApp provider 授權指南與provider 訊息支援矩陣，評估這條獨立的路徑。

來源