內容摘要
- Meta 於 2026 年開放 WhatsApp Groups API，企業須符合每日 100,000 則商業訊息或持有官方企業帳號（OBA）門檻，每組人數上限為 8 人。
- WhatsApp Groups API 商業應用的核心價值在於多方個案協作、VIP 客戶私密服務及排期分組管理，而非取代大規模廣播行銷。
- Groups API 沿用 Meta 既有的 24 小時對話窗口及範本訊息收費機制，企業若群組數量及發送頻率增加，範本訊息成本會隨之上升。
Meta於2025年10月正式推出WhatsApp Groups API，讓符合資格的WhatsApp Business Platform企業以Cloud API建立及管理群組。到了2026年，目前Meta的Groups API文件顯示，功能已開放予具備Official Business Account（OBA）資格的企業使用。對於需要處理 VIP 客戶諮詢、多方協作或複雜個案跟進的企業而言，這是一項值得認真評估的新工具。本文將全面拆解 Groups API 的運作方式、規則限制及實際應用場景，協助你判斷企業應在甚麼情況下採用，甚麼情況下應該繼續使用標準廣播或一對一訊息。
甚麼是 WhatsApp Groups API
WhatsApp Groups API 是 Meta 官方 WhatsApp Cloud API 的延伸功能，讓已獲授權的企業（擁有官方企業帳號，即 Official Business Account，OBA）能夠以程式化方式建立及管理小型 WhatsApp 群組對話（Sanuker，2025）。根據 Meta 的說明，目前使用Groups API的核心帳戶資格是Official Business Account（OBA），並需使用符合資格的Cloud API號碼。目前Meta的Groups API資格以Official Business Account（OBA）為核心，並要求使用符合資格的Cloud API號碼。早期部分文件曾列出額外的100,000 messaging-limit門檻，但該要求已不再出現在目前的Groups API資格說明中。
Groups API 的運作核心是「邀請制」，而非強制拉人入群，這一點與一般消費者使用的 WhatsApp 群組有明顯分別。企業建立群組後，系統會自動生成一個包含群組主題及描述的專屬邀請連結，企業可將專屬invite link分享給目標客戶；常見做法是透過獲批的Group Invite Link Template在一對一WhatsApp對話中發送。部分平台亦允許企業直接複製邀請連結，再透過合適渠道分享。無論採用哪種方式，用戶都必須自行選擇加入。企業無法透過 API 強行將用戶加入群組，這種invite-only設計讓是否加入群組的決定保留在用戶手上，企業不能透過API直接把WhatsApp用戶加入群組。當客戶成功加入後，系統會即時觸發 Webhook 通知（例如 group_participants_update），讓企業取得在群組內發送訊息的權限，並可據此啟動自動化工作流程。
你可以將這個機制想像成會所的會員邀請制度：企業無法隨意把人拉入私人會所，但可以主動發出邀請函，對方接受邀請、簽署入會後，才能正式進入並享用會所內的服務。這種設計既維持了群組對話的私密感，也確保所有加入者都是自願且知情的。
Groups API 的主要限制有哪些
Meta 對 Groups API 設下了清晰的參數限制，企業在規劃應用場景前必須先了解清楚：
限制項目 | 官方規定 |
|---|---|
每組最大人數 | Meta層面每組最多8名participants，包括建立群組的business number，因此實際最多為7名外部WhatsApp用戶。Wati目前亦以最多7名external participants呈現此限制，而Wati內部operators不計入這7人上限。 |
每個商業電話號碼最多活躍群組數 | Meta Groups API的上限為每個business number最多10,000個groups；但實際BSP可以設置較低平台上限。以Wati目前為例，每個WhatsApp號碼最多建立1,000個群組。 |
使用資格 | 持有官方企業帳號（OBA）的企業 |
支援訊息類型 | Meta Groups API支援文字、媒體、text-based templates及media-based templates。Authentication templates、interactive messages、commerce messages、WhatsApp Calling、disappearing messages及view-once media目前不支援。就Wati而言，目前群組支援Marketing及Utility templates，但不支援Authentication templates。 |
不支援功能 | 語音/視像通話、閱後即焚訊息、單次查看媒體、互動式按鈕/清單、目錄訊息 |
這張表格說明了一個重要事實：Groups API 並非設計來取代廣播訊息的規模化推廣功能。每組上限僅 8 人，加上不支援互動按鈕、目錄訊息等常見於行銷場景的功能，這項工具的定位明顯是深度服務，而非大量觸及。
Groups API 與傳統 WhatsApp 群組有何分別
不少企業過去依賴員工用個人或 WhatsApp Business App 手動管理群組聊天，隨著業務規模擴大，這種做法容易造成營運瓶頸及合規風險。
在工作流程及營運效率方面，傳統群組完全依靠人手操作：員工需要逐一搜尋聯絡人、手動加入、手動傳送檔案，項目完結後亦要自行退出或刪除群組，一旦同時處理多名客戶，出錯機率相當高。相反，Groups API 可直接連接企業的 CRM 或工單系統，例如客戶在網站提交支援請求後，系統自動建立群組並生成邀請連結，連結經一對一訊息自動發送，客戶加入後觸發團隊分配，個案解決後群組亦可自動關閉。
在對話留存及合規方面，以員工個人或Business App帳戶管理客戶群組時，對話紀錄及存取權往往分散於不同裝置或帳戶，企業較難統一管理保留政策、權限及CRM紀錄；當人員轉職或裝置更換時，亦可能增加資料交接及治理風險。Groups API提供群組訊息及participant、lifecycle、settings等Webhook事件，企業可把相關事件寫入CRM或合規紀錄系統，協助建立較完整的audit trail。不過API本身並不自動保證符合法規；資料保留、存取控制、同意管理及行業監管要求仍需由企業及所使用的平台另外落實。這一點對於金融、醫療美容等高度監管的行業尤其重要。
在收費模式方面，一般WhatsApp／WhatsApp Business App群組本身不提供Groups API所具備的Cloud API級程式化建立、participant management及webhook integration能力；若企業需要把群組事件寫入CRM或自動觸發後續流程，通常需要額外工具或平台協助。Groups API同樣設有24小時Customer Service Window，但應避免把它直接稱為『免費窗口』。任何group participant在群組內發訊息，都會為整個群組開啟或刷新同一個24小時窗口。截至2026年9月30日，group service messages及窗口內的group utility messages可享免費customer-service待遇，而Marketing templates仍然計費。一旦窗口關閉，企業要再發送訊息便需要使用已預先審批的範本訊息（Template Messages），Groups API的billable messages是按『成功送達的recipient』計費，而不是整個group send只計一次。例如一則Marketing template發送到包含7名外部成員的群組並全部成功送達，Meta會計算7次delivery，並按每名收訊人的country rate收費。需要特別留意，Meta將於2026年10月1日調整Service Messages及窗口內Utility Messages的整體收費政策。Wati目前的Groups文件亦指出，自10月1日起，群組客服窗口內的free-form及Utility訊息將改為按訊息計費。自2026年10月1日起，24小時Customer Service Window內的free-form service messages及Utility templates亦會改為按訊息計費；Marketing templates則繼續收費。因此，10月1日後的24小時窗口主要決定企業能否發送free-form messages，而不應再理解為『窗口內訊息免費』。
值得留意的是，這裡描述的 24 小時窗口及範本訊息收費機制，是 Meta 平台層面本身既有的計價方式，並非某個訊息平台的獨有安排。因此，企業在評估成本時應以 Meta 官方的計價原則為準，而非套用個別服務商的帳單模式。
Groups API 適合甚麼商業應用場景
由於每組上限僅 8 人，Groups API 的設計定位明顯是針對高價值個案、複雜服務流程以及多方協作，而非大眾行銷。以下是三類最具代表性的應用場景。
多方個案處理。 當服務流程涉及多個相關人員時，單純靠一對一訊息轉達容易造成資訊落差。個案建立後，Groups API 可自動生成群組，邀請客戶、專責客服、技術專家或外部供應商同時進入一個聊天室，加快問題解決速度。例如婚禮策劃公司可自動建立包含新人、統籌、化妝師、攝影師及場地經理的專屬群組，協調時間表、化妝試妝相片及臨時調動；裝修公司則可為每個項目建立包含業主、室內設計師、項目經理及主要承辦商的群組，發送工地進度照片、確認材料樣本，並即時多方討論解決結構問題。
VIP 客戶私密服務。 對於高淨值或 VIP 客戶而言，企業可建立包含客戶顧問、產品專員及高級經理的專屬小組，提供具個人化、資訊豐富的服務環境。例如金融機構可讓專責客戶經理及投資顧問與 VIP 客戶建立 3 至 4 人的私密群組，定期提供投資組合建議及檢討，如用於金融、醫療或其他受監管場景，企業可以把Groups API產生的訊息及Webhook事件納入既有的record retention及audit系統；但由於群組參與者可以看到共享對話內容及其他成員，企業必須另外評估用戶同意、敏感資料披露、資料保留及所在地監管要求。Groups API本身並不代表該使用場景已符合監管要求。
排期分組管理與進度追蹤。 適用於分批次或固定排期的服務，企業可將小批量客戶分組管理，管理員可自動化提醒、排期及清單，同時讓組員在同一對話串內提問。例如補習社或語言中心可為固定排期的小班（例如「IELTS 星期六上午 10 時班」）建立群組，包含一名導師及 5 至 6 名學生，自動發送上課提醒、功課及練習連結；健身中心亦可為結伴參加減重或訓練計劃的 3 至 4 位朋友建立群組，方便教練發送每日營養提示及訓練清單。
Groups API vs 廣播訊息 vs 一對一 API 訊息：如何選擇
企業在規劃訊息策略時，可以按照下列原則區分三種模式的適用場景：
訊息模式 | 最適合場景 | 規模 | 私密程度 |
|---|---|---|---|
一對一 API | 私人客服、銷售、售後 | 單一客戶 | 最高：僅企業與該客戶 |
WhatsApp 廣播 | 一對多行銷推廣、節日祝福、大量公告 | 大量客戶（數千至數萬） | 高——每名收訊人收到獨立的一對一訊息，彼此看不到其他收訊人。 |
WhatsApp Groups API | 多方協作、VIP 客戶管理、需要完整對話紀錄的個案跟進 | 小型群組（上限 8 人） | 較低於1:1／Broadcast——group members可以看到共同對話及其他participants。 |
簡單來說，如果目標是觸及最多人，廣播訊息仍然是最有效率的選擇；如果是單一客戶的個人化服務，一對一訊息已經足夠。但如果案件本質上需要多個角色同時在場、即時協作，而且要保留完整可審查的對話紀錄，在WhatsApp Business Platform這三種模式之中，Groups API是唯一提供共享多方對話thread的選項。企業不應將 Groups API 視為廣播訊息的替代品，兩者服務的商業目的截然不同，硬要用群組功能取代大規模行銷推廣，只會浪費 8 人上限的群組資源，亦無法達到觸及規模。
一個常見的誤解，是以為 Groups API 可以完全取代人手管理的客戶群組，並降低所有訊息成本。實際上，Groups API 的 24 小時窗口與範本訊息收費機制與一般 API 訊息一致，企業若在窗口關閉後頻繁發送範本訊息通知群組內多名成員，實際成本可能比預期中高。在大量群組環境下，企業更需要規劃訊息觸發頻率及群組生命周期。Meta的平台上限為每個business number 10,000個groups；如使用Wati，目前則以每個WhatsApp號碼最多1,000個群組為限。
甚麼保持不變
在評估 Groups API 帶來的變化時，有幾點需要清楚分開來看，避免誤以為整個 WhatsApp Business Platform 的收費及規則都已經全面改變。
一對一訊息及廣播訊息的既有規則並無改變，24 小時客戶服務窗口、範本訊息審批流程及既定的訊息分類（例如 Utility 範本、Marketing 範本）繼續適用，Groups API 只是在此之上新增的一層群組協作能力，並非取代現有機制。有的一對一API流程可以繼續與Groups API並行，但企業不能假設既有chatbot及automation可原封不動套用至群組。Groups使用獨立的group conversation、participant及lifecycle events，亦有不同的message-type限制，因此涉及routing、participant events或自動化判斷的流程通常需要增加相應的group handling。
如何開始部署 WhatsApp Groups API
在正式導入 Groups API 之前，企業需先符合以下前提條件：若直接使用Meta Cloud API，企業需具備OBA資格、使用符合條件的Cloud API號碼、取得whatsapp_business_messaging權限，並訂閱相關Groups webhook fields；WhatsApp Business App、Coexistence及Multi-solution Conversations號碼目前不符合Groups API要求。若透過Wati等BSP使用，部分底層webhook及API處理則可由平台代為承接。
完成前提條件後，實際部署可分為三個核心步驟。第一步是建立群組，輸入群組主題及描述，成功建立後系統會生成該群組的專屬邀請連結。第二步是把invite link分享給目標客戶。企業可透過Group Invite Template在一對一WhatsApp對話中發送；若使用Wati，系統會向加入待邀請名單的contact發送invite link，企業亦可複製連結並透過合適渠道手動分享。第三步是透過 Cloud API 或訊息管理平台，向已加入的用戶發送文字、媒體或範本訊息，每一則訊息或狀態更新都會觸發 Webhook 紀錄，方便日後審查及團隊協作。
Wati目前在Business Plan提供原生WhatsApp Groups功能及Groups API。企業可在Wati內建立群組、邀請contacts、加入operators，並從Team Inbox管理group conversations；亦可透過Wati Groups API建立／刪除群組、發送邀請、移除participants及查詢active groups。Wati目前明確支援Team Inbox與Groups API，Wati目前明確支援Team Inbox及Groups API，包括建立／刪除群組、發送邀請、移除participants及查詢active groups。Campaign broadcasts目前不支援WhatsApp Groups；至於Chatbot Builder，現有公開文件亦未確認可直接套用到group conversations，因此不應把既有chatbot automation描述為Groups的標準功能。
WhatsApp Groups API 的出現，標誌著 WhatsApp Business Platform 由單純的訊息推送工具，進一步演變成能夠支援多方協作、深度服務的營運基礎設施。它不會取代廣播訊息或一對一對話，而是在企業的訊息策略中填補了一個過去只能靠人手勉強應付的空隙，讓 VIP 服務、複雜個案跟進及排期式管理都能被自動化、可追蹤地執行。真正的問題不在於這項工具是否強大，而在於企業有沒有把握清楚：哪些個案值得投放這種深度、小規模的協作資源，哪些其實只是換了包裝的人手工作。
準備好了解 Wati 如何為你提供協助？立即預約免費示範，親身體驗其強大功能。
常見問題
甚麼是 WhatsApp Groups API？
WhatsApp Groups API 是 Meta 官方 WhatsApp Cloud API 的延伸功能，讓已獲授權的企業能夠以程式化方式建立及管理小型 WhatsApp 群組對話。企業建立群組後會取得一個專屬邀請連結，客戶必須主動點擊連結加入，企業無法強行將人拉入群組。加入後系統會觸發 Webhook 通知，讓企業取得在群組內發送訊息及自動化管理的權限，每組人數上限為 8 人。
WhatsApp Groups API 與 WhatsApp 廣播訊息有甚麼分別？
兩者服務的商業目的完全不同。廣播訊息是一對多的行銷工具，適合大量客戶的推廣及公告，觸及規模可達數千至數萬人。Groups API 則是小型多方協作工具，每組上限僅 8 人，適合需要客戶、客服、專家等多個角色同時參與並保留完整對話紀錄的個案，例如 VIP 服務或多方個案跟進，並不適合用來取代大規模行銷推廣。
企業應如何開始部署 WhatsApp Groups API？
企業首先需要確保電話號碼已註冊於 Meta 官方的 WhatsApp Cloud API，並具備接收 Webhook 通知的伺服器架構。之後分三步進行：建立群組並取得專屬邀請連結；透過一對一訊息將連結發送給目標客戶，待對方加入後系統會觸發通知；最後透過 Cloud API 或訊息管理平台向群組發送文字、媒體或範本訊息，並利用 Webhook 紀錄追蹤所有互動，方便團隊協作及日後審查。
在香港市場，企業使用 Groups API 需要留意甚麼實際問題？
香港企業普遍高度重視客戶私隱及對話合規紀錄，尤其金融及醫療美容行業。Groups API 的邀請制設計及系統級 Webhook 紀錄，正好配合這類需要留存審查紀錄的行業需求。企業亦要留意，24 小時窗口關閉後發送範本訊息仍按地區費率收費，若群組數量及發送頻率增加，成本會隨之上升，建議在導入前先評估預期使用量，避免範本訊息被重複、不必要地觸發。