WhatsApp Coexistence 畀你同時用商業應用同 Cloud API——但你真係需要兩邊都用？
Meta 喺 2026 年向 14 個以上國家同地區全面推出咗 WhatsApp Coexistence 功能，解決咗一個困擾 WhatsApp 商業用戶多年嘅問題：以前你只可以喺商業應用（手動、手機端操作）同 Cloud API（自動化、webhook 驅動）之間揀一個。用咗一個就冇咗另一個。Coexistence 畀你喺同一個號碼上同時運行兩者，訊息即時同步。
呢個確實係一項有意義嘅改進。但值得問一句：你嘅團隊真係需要兩邊都用？
Coexistence 提供咗乜嘢
Coexistence 令 WhatsApp 商業應用同 Cloud API 之間嘅每一筆一對一對話都即時鏡像。客戶傳訊息到你嘅號碼，訊息同時出現喺手機上嘅商業應用同 Cloud API 嘅 webhook 事件入面。從任何一端發出嘅回覆都會喺幾秒內同步到另一端。
實際場景：銷售團隊用手機回覆，客服隊列走自動化系統，雙方睇到同一筆對話。唔使轉發、唔使備用號碼、唔使「去另一個頻道睇吓」。
Meta 仲會喺啟用 Coexistence 時回填最多六個月嘅歷史一對一訊息，API 端唔會由空嘅收件匣開始。
Coexistence 需要乜嘢條件
條件清單揭示咗呢個功能嘅目標用戶：
1. 已批核嘅 Cloud API 整合。 你嘅 WhatsApp 商業帳號必須透過 Meta 嘅入門流程接入 Cloud API——直接對接或者透過 BSP（商業解決方案供應商）。即係話要完成商業驗證、設定 Meta Business Portfolio、喺 Meta 開發者控制台配置 webhook 端點。
2. 正確嘅商業應用版本。 WhatsApp 商業應用 2.24.17 或更新版本，舊版唔支援同步協議。
3. 熱身期。 手機號碼喺啟用 Coexistence 之前必須喺商業應用上活躍使用最少 7 日。Meta 建議 1–2 個月嘅持續使用以確保同步穩定。唔可以註冊新號碼就即刻啟用兩端。
4. 14 日心跳。 啟用 Coexistence 之後，你必須最少每 14 日開啟一次商業應用。如果應用休眠，同步會靜默中斷——API 端嘅訊息照常送達，但應用端變暗。你嘅銷售團隊喺有人重新開啟應用之前都睇唔到訊息。
5. BSP 基礎設施（大多數場景下）。 除非你直接對接 Meta 嘅 Cloud API（大多數細團隊唔會咁做），否則你係透過 BSP 接入。即係話有平台費（$29–$500+/月）、每條訊息加價（通常 15–20%）同範本管理嘅額外負擔。
三類適合 Coexistence 嘅團隊
唔係所有 WhatsApp 配置都可以從雙端運行受益。Coexistence 適合特定嘅團隊畫像：
團隊 A：銷售用手機，客服走自動化。 外勤銷售用商業應用回覆，後端系統處理訂單確認同路由。雙方需要睇到同一筆對話。Coexistence 直接解決呢個問題。
團隊 B：從商業應用遷移到 Cloud API。 團隊一開始用商業應用，正在逐步加入 API 自動化。Coexistence 畀佢哋喺過渡期同時運行兩端，唔使轉號、唔會丟失應用端嘅工作流程。
團隊 C：合規要求人工審核。 法規要求喺自動訊息發出前有人工審核。應用端提供審核介面，API 端提供自動化。
唔適合嘅嗰類團隊
仲有第四類團隊，喺 Meta 嘅 Coexistence 文件入面搵唔到佢：只接收訊息嘅團隊。
呢啲團隊唔發營銷廣播、唔用範本訊息、唔需要商業應用嘅手動回覆介面——因為佢哋嘅客服隊列已經由工單系統、CRM 或 AI 代理管道處理。佢哋從 WhatsApp 需要嘅唯一嘢係入站訊息——以結構化事件嘅形式送達，方便路由、記錄同處理。
對呢類團隊嚟講，Coexistence 喺一個佢哋唔需要嘅功能嘅兩側都增加咗基礎設施：
- Cloud API 端： 商業驗證、Meta 開發者控制台、webhook 配置、BSP 合約、每條訊息計費（雖然服務對話免費，但逾時回覆會變成範本計費——詳見 7 月費率分析）
- 商業應用端： 14 日心跳要求、應用版本管理、熱身期、需要團隊入面有人保持手機活躍
兩端之間嘅同步先係呢個功能嘅核心。如果你兩端都唔需要，咁同步就係額外負擔。
跳過兩端嘅路徑
UnifyPort 嘅非官方介面連接一個普通 WhatsApp 帳號——唔使商業驗證、唔使 Cloud API 批核、唔使 BSP——將每條入站訊息以標準化嘅 webhook 事件送達：
{
"event": "message.received",
"account_id": "acct_7kQnWx",
"provider": "whatsapp",
"from": "user_d4f29a",
"text": "請問有寄到新加坡嗎？",
"timestamp": 1751270400,
"message_id": "wa_msg_8b3e71"
}你嘅後端用 signing_secret 驗證 HMAC-SHA256 簽章，然後將訊息路由到現有隊列。唔使保持商業應用活躍，唔使配置 Cloud API，唔使維護 14 日心跳，冇 BSP 加價喺意外範本計費上複利。
回覆透過 POST /v1/messages 發送——單一端點，冇範本分類，冇對話窗口計費。同一個 webhook 端點接收嚟自 Telegram、LINE、TikTok、Zalo 同 X 嘅訊息，用相同嘅 message.received 格式。喺現有多平台系統入面加上 WhatsApp 唔會增加新嘅計費模型——只係喺 payload 入面多咗一個 provider 值。
決策矩陣
| 條件 | Coexistence | UnifyPort |
|---|---|---|
| 商業驗證 | 必需 | 唔需要 |
| BSP 合約 | 通常需要 | 唔需要 |
| 手機應用每 14 日活躍 | 必需 | 唔需要 |
| 出站營銷範本 | 支援 | 唔係使用場景 |
| 入站訊息 webhook | 係（Cloud API 端） | 係 |
| 多平台（Telegram、LINE 等） | 需分別整合 | 同一 webhook |
| 每條訊息計費 | Meta 費率 + BSP 加價 | 冇 |
| 部署時間 | 數日到數週（驗證流程） | 數小時 |
邊個係你嘅場景
如果你嘅團隊發出站營銷、需要商業應用畀外勤銷售用、或者正在將現有商業應用工作流程遷移到 API 自動化——Coexistence 係你等咗好耐嘅功能，佢解決咗 WhatsApp 基礎設施入面嘅一個真實缺口。
如果你嘅團隊只係接收訊息、路由到隊列、透過現有系統回覆——問題唔係「要唔要啟用 Coexistence」，而係「我哋係咪需要 Coexistence 所連接嘅嗰啲基礎設施」。對於純入站工作流程，答案可能係：兩端都唔需要。
完整 API 參考同 webhook 文件：unifyport.ai/docs。