快速閱讀：WhatsApp Cloud API 是 WhatsApp Business Platform 的程式介面：你的系統向 phone number ID 的 /messages 端點 POST JSON，即可發送文字、媒體、互動元件或範本。客戶傳給你的內容，以及每則外發訊息的送達／已讀等狀態，都經 Webhooks 推送到你登記的 HTTPS 網址。沒有穩定的 Webhook，等於看不見入站、也對不了帳單上的已送達則數。
本文核對日期為 2026年9月28日。費率、免費額度與產品介面會改，下單與預算請以 Meta 當期費率卡、WhatsApp Manager 與 Messaging 帳戶帳單為準。本文不是 Meta 官方文件的逐字翻譯，也不構成帳單、法律或技術實施承諾。
WhatsApp Cloud API 讓系統用 Graph API 發送加密訊息。能力說明見 Cloud API 概覽；發送細節見 發送訊息；事件見 Webhooks 參考。
WhatsApp Cloud API 發送訊息的基本形狀
請求送到 https://graph.facebook.com/<API_VERSION>/<WHATSAPP_BUSINESS_PHONE_NUMBER_ID>/messages，標頭帶 Authorization: Bearer 與 JSON。常見 type 包括 text、image、interactive、template。範本是唯一可在客戶服務視窗外主動聯絡用戶的訊息類型（須核准與選擇加入）。
10月1日之後，視窗內每一則已送達的非範本回覆都可能消耗免費額度或變成 REGULAR 費用，因此 API 重試、重複 Webhook 與「同一內容連 POST 兩次」會直接反映在帳單。發送前應做冪等設計。
WhatsApp Cloud API 的客戶服務視窗與訊息類型
客戶傳訊給商業號碼後，開啟客戶服務視窗，企業可在視窗內發送自由格式訊息。視窗會在客戶再次傳訊時重設。視窗外的訂單提醒、驗證碼、促銷，應走對應分類的範本。行銷、通用、驗證的分類規則見 訊息範本與範本分類。
互動訊息（按鈕、列表）仍是「一則」。用選單減少來回，比連發三則文字更符合 2026 年的計費邏輯。需要一次收集多個欄位時，優先 WhatsApp Flows。
WhatsApp Cloud API 為什麼幾乎一定要接 Webhooks
平台高度依賴 Webhooks：用戶發給你的訊息內容經 Webhook 到達；你發出的訊息是否已送達、失敗、已讀，也經 Webhook 回報。沒有 Webhook，客服系統看不到入站，財務也無法把「API 回 200」與「Meta 認為已送達」分開。
營運上至少要處理：URL 驗證、payload 簽名、重複投遞、錯誤碼（例如配對限速 131056）、以及 10月1日起服務訊息因未登記付款方式而送達失敗的情況。狀態應寫回 CRM，而不是只存在個人手機。
WhatsApp Cloud API 的速率、吞吐與測試資源
商業號碼預設吞吐可達每秒 80 則，並可升級。Coexistence 共用號碼時，文件另有每秒 20 則的上限，見 Coexistence。對同一使用者有配對速率限制。新建立的測試帳戶與測試號碼限制較寬，適合在正式號碼上線前驗證範本與 Webhook。
完整平台地圖見 WhatsApp Business Platform 指南。收費字段見 WhatsApp 收費改制。
內容審閱：2026年9月｜作者／審閱：Timson Kwok（trafficholic 創辦人）。觀點來自真實合作流程、渠道數據觀察與企業 AIO／AI Search 落地經驗；數字會隨平台演算法更新，請以當期後台為準。非金融／法律意見。
WhatsApp Cloud API 常見問題
沒有開啟視窗時可以發普通文字嗎？
一般不可以。自由格式訊息需要開啟中的客戶服務視窗。視窗外應使用已核准的訊息範本，並遵守選擇加入與範本分類規則。
Webhooks 一定要自己架伺服器嗎？
Cloud API 本身需要一個可驗證的 HTTPS 接收端。香港企業多數經 BSP 或中介系統接收，但仍應知道失敗重試、簽名驗證與錯誤代碼會影響客服是否漏訊。
已送達和已讀哪一個計費？
平台訊息費按已送達（delivered）的計費類別計算，不是按已讀。Webhook 的 status 應用來對帳與除錯，而不是用已讀當帳單。
對同一客人連發會不會被限速？
會。文件說明商業號碼對同一 WhatsApp 使用者約每 6 秒 1 則，爆發後需等待。超過可能出現錯誤碼 131056。這與 10月1日之後「分段發送變貴」是兩件疊加的事。
