摘要
WhatsApp Business API 允許中大型企業根據規模與客戶進行溝通。企業可以將 API 整合到其系統中，以管理自動化和人工客戶互動。
WhatsApp Business API 提供兩種托管選項：
雲端 API（由 Meta 托管）
本地架設 API（由企業或 Business Solution Providers (BSPs) 自行架設）
選擇適合您的選項取決於您的業務需求。此指南將雲端 API 與本地架設 API 的差異進行分析，幫助您決定哪種類型最適合您的使用情況。
重要提示： 同一時間僅能將一個電話號碼與 這兩種 API 之一註冊。無法在同時使用兩種平台上的相同號碼。
說明
雲端 API 概覽
雲端 API 由 Meta 托管，允許企業透過 Graph API 發送訊息。它使用 網路鉤子 (webhooks) 接收傳入訊息和傳送狀態等事件。
主要功能：
無需伺服器維護 – Meta 負責托管和基礎設施管理。
自動更新 – 企業始終可獲得最新功能和安全性補丁。
較高的訊息貫通量 – 支援至多 每秒 500 則訊息（即傳送和接收的總合）。
簡化驗證 – 使用 用戶存取權杖。
較低的基礎架構成本 – 企業僅需為傳送的訊息付費。
如需了解更多，請參閱 Graph API 開發人員文件。
本地架設 API 概覽
本地架設 API 要求企業或 BSP 在自己的伺服器上托管和維護 WhatsApp API 軟體。
主要功能：
更多控制權 – 企業管理自己的基礎架構。
自訂安全性 – 企業控制自己的 授權單位 (Certificate Authority, CA) 和網路鉤子 (webhook) 憑證。
支援 Check Contacts API 和 Media Provider API，這些功能在雲端 API 中已淘汰。
根據業務基礎架構，可實現較低延遲的本地部署。
需要高可用性 – 企業必須實作災害復原方案。
比較：雲端 API 與本地架設 API
功能 | 雲端 API（由 Meta 托管） | 本地架設 API（自行架設） |
托管 | 由 Meta 托管 | 企業/BSPs 在自己的伺服器上托管 |
維護 | Meta 處理升級和補丁 | 企業/BSPs 必須管理更新和擴展 |
成本 | 企業按傳送的訊息付費 | 伺服器設定與維護的附加基礎架構成本 + 每則訊息收費 |
API 通訊協定 | Graph API | REST API |
訊息貫通量 | 至多 每秒 500 則訊息（傳送與接收合併） | 至多 單連接每秒 70 則訊息，多連接每秒 250 則訊息 |
憑證管理 | 由 Meta 管理 | 企業管理自己的憑證 |
災害復原 | Meta 確保線上運作（目標 99.9%） | 企業必須實作備援方案 |
單租戶 vs. 多租戶 | 多租戶（支援多個電話號碼） | 單租戶（每個部署一個電話號碼） |
監控 | Meta 監控實例健康狀況 | 企業必須自行設定監控 |
基本錯誤率 | 約 0.1% | 未發佈；取決於基礎架構 |
伺服器位置 | 北美 | 由企業基礎架構決定 |
SLA（線上時間） | 目標 99.9% 線上時間 | 取決於企業設定 |
支援 | 對關鍵問題提供全天候支援 | 對關鍵問題提供全天候最佳努力支援 |
選擇雲端 API 與本地架設 API 的主要考量因素
何時選擇 雲端 API
您 不想管理伺服器 和基礎架構。
您需要 擴展性 且希望盡量少費心。
您希望 自動更新 且不需要停機。
您的企業需要 高負載 的訊息能力（每秒 500 則訊息）。
何時選擇 本地架設 API
您需要 完全控制基礎架構和安全性。
您的企業由於 監管限制，無法使用 Meta 托管的服務。
您依賴 Check Contacts API 和 Media Provider API（在雲端 API 中已淘汰）。
您有 現有的基礎架構 和資源可用於伺服器管理。
雲端 API 中的淘汰功能
本地架設 API 中的一些功能在雲端 API 中已淘汰：
功能 | 本地架設 API | 雲端 API |
Check Contacts API | 在傳送訊息前需驗證電話號碼 | 不再需要 – 直接使用電話號碼 |
Media Provider API | 在此支援 | 已淘汰 – 使用 雲端 API 上傳媒體步驟 |
結論
選擇 雲端 API 和 本地架設 API 取決於您的業務需求：
雲端 API 最適合追求 便利性、低維護和擴展性 的企業。
本地架設 API 最適合需要 完全控制、自訂安全性和本地架設 的企業。
如果仍不明確，請在做出決定前考慮您的基礎架構能力、安全性需求和擴展性需求。
常見問題解答（FAQs）
一般問題
1. 什麼是 WhatsApp Business API？
→ lng>WhatsApp Business API 允許企業根據規模與客戶進行溝通，啟用自動化和人工發送訊息功能。
2. WhatsApp Business API 有哪兩種托管選項？
→ 有兩種托管選項：
雲端 API – 由 Meta 托管，不需進行伺服器維護。
本地架設 API – 由企業或 Business Solution Providers (BSPs) 自行架設，需負責伺服器管理。
3. 是否可同時使用雲端 API 和本地架設 API？
→ 否，電話號碼同一時間只能註冊在一個平臺上使用。
雲端 API
4.什麼是雲端 API？
→ 雲端 API 是 Meta 托管的 WhatsApp Business API，可讓企業透過 Graph API 發送訊息而不需管理自己的基礎架構。
5. 使用雲端 API 有什麼好處？
不需架設或維護伺服器。
自動提供新功能和安全性補帶的更新。
較高訊息貫通量（每秒至多 500 則訊息）。
較低的基礎架構成本（僅針對傳送的訊息付費）。
6. 雲端 API 伺服器位於何處？
→ 雲端 API 伺服器托管在 北美。
7. 雲端 API 使用何種驗證方式？
→ 雲端 API 使用 用戶存取權杖 進行驗證。
8. 雲端 API 是否支援 Check Contacts API 或 Media Provider API？
→ 否，這些 API 在雲端 API 中已淘汰。
本地架設 API
9. 什麼是本地架設 API？
→ 本地架設 API 是 WhatsApp Business API 的自行架設版本，企業或 BSP 必須在自己的伺服器上管理。或
10. 使用本地架設 API 有什麼優勢？
完全控制基礎架構和安全性。
可管理憑證和符合資格要求。
可部署到 高可用性 模型以進行災害復原。
支援 Check Contacts API 和 Media Provider API（這些 API 已在雲端 API 中淘汰）。
11. 本地架設 API 的基礎架構需求是什麼？
→ 企業必須設定和維護自己的伺服器，管理授權單位 (CA)，並監控系統健康狀況。
12. 貫通量與雲端 API 相較如何？
本地架設 API 可支援至多 單連接每秒 70 則訊息 和 多連接每秒 250 則訊息。
雲端 API 可支援至多 每秒 500 則訊息（傳送和接收合併）。
13. 本地架設 API 可托管在何處
→ 可托管在企業選擇的任意資料中心或雲端提供商。
選擇雲端 API 和本地架設 API
14. 如何在雲端 API 和本地架設 API 之間做出選擇？
如果您偏好最少維護、自動更新，以及較高的消息貫通率，請選擇 雲端 API。
如果您需要對安全性、基礎設施和自定義部署有完全的控制，請選擇 本地架設 API。
15. 雲端 API 的線上時間比本地架設 API 更好嗎？
→ 雲端 API 目標為 99.9% 線上時間，而本地架設 API 的線上時間則取決於企業的基礎架構。
16. 雲端 API 可否減少成本？
→ 可以。雲端 API 消除了 伺服器設定與維護成本，因此企業僅需為傳送的訊息付費。
17. 是否可從本地架設 API 遷移到雲端 API？
→ 可以，但您必須在註冊於雲端 API 之前 trafic Please deregister your phone number from On-Premises API.
支援與維護
18. 誰管理雲端 API 的更新？
→ Meta 會自動處理 軟體更新與安全性補丁 以供雲端 API 使用人員運用。
19. 誰負責維護本地架設 API？
→ 企業或 BSP 必須自行執行升級、安全性更新與伺服器監控。
20. 有哪些支援選項適用於這兩種類型 API？
雲端 API：針對關鍵問題提供 24/7 支援。
本地架設 API：針對關鍵問題提供全天候最佳努力支援。