以下狀況可能會造成訊息顯示為已傳送但未送達。由於其中有許多原因,基於隱私和政策理由,我們不會透露錯誤的根本原因。
在某些狀況下,API 將傳回錯誤代碼,內含說明錯誤性質的錯誤訊息。狀況範例:
使用非 WhatsApp 通訊方式,要求 WhatsApp 用戶執行以下動作:
古巴、伊朗、北韓、敘利亞和烏克蘭三個受制裁地區(克里米亞、頓涅茨克、盧甘斯克)的商家不符資格,無法使用 WhatsApp Business 平台。
古巴、伊朗、北韓、敘利亞和烏克蘭三個受制裁地區(克里米亞、頓涅茨克、盧甘斯克)的 WhatsApp Messenger(WhatsApp)和 WhatsApp Business 應用程式用戶不符資格,無法接收透過 WhatsApp Business 平台傳送的訊息。
自 2024 年 5 月 15 日起,土耳其不再受到雲端 API 商務式訊息傳送功能的限制。雲端 API 商家現在可以向使用土耳其號碼的 WhatsApp 用戶發起對話及接收訊息。
在極少數狀況下,同一訊息可能會同時觸發成功和失敗訊息狀態更新 Webhooks。例如,訊息可能會觸發包含 "status":"delivered"
的訊息 Webhooks 和另一個包含 "status":"failed"
的 Webhook。當顧客在多部裝置上登入 WhatsApp,並將訊息成功傳送到其中一部裝置但未成功傳送到另一部裝置時,就會發生此狀況。系統已將觸發 "delivered"
訊息狀態 Webhook 的任何訊息送達到至少一部用戶裝置。
2
- API 服務當我們更新 API 時,您可能會遇到長達 5 分鐘的停機時間。在此期間,系統將無法提供服務。我們嘗試在對業務造成最低干擾的情況下進行這些更新,但您最終可能還是會受到影響
建議您等待 5 分鐘後,再嘗試進行 API 呼叫。
當您用於 API 呼叫的存取權杖發生問題時,系統將傳回這些錯誤。
您可以直接將使用中的存取權杖貼到存取權杖偵錯工具中,然後檢查是否已選擇 whatsapp_business_management
和 whatsapp_business_messaging
權限。
如果權杖無法存取權限,則需要產生新權杖。產生權杖時,請務必選擇下列項目:
whatsapp_business_management
和 whatsapp_business_messaging
WhatsApp develops and operates the WhatsApp Business API, which enables businesses to communicate with WhatsApp consumer users on the WhatsApp network. When using the Cloud API, Meta will host the WhatsApp Business API for you and provide an endpoint for the WhatsApp service for your incoming and outgoing WhatsApp communications.
Please view information about the sunset of the On-Premises API.
Access to Cloud API is free, and we expect it to generate additional cost savings for developers, as Meta hosts and maintains the Cloud API.
We want to make it clear what it means to message with a business on WhatsApp. Some businesses may choose to use Meta or another company to help them manage and store their messages. When a business chooses to manage their messages with another company, we will let consumers know by showing a different system message. Learn more.
The Cloud API architecture significantly simplifies the Solution Partner's operational and infrastructure requirements to integrate with WhatsApp Business Platform. First, it removes the infrastructure requirements to run Business API docker containers (CAPEX savings). Second, it obviates the need of operational responsibilities to manage the deployment (OPEX savings). For details, refer to the architecture diagram comparing the On-Premises and Cloud API deployments.
Solution Partners and direct clients do not need the WebApp and CoreApp containers that are used in the On-Premises API. Meta will manage all database data and media data on behalf of the Solution Partner or direct client.
As your on-premises performance depends heavily on your hardware, software, and connectivity to WhatsApp servers, if you wish to understand these differences, you can perform your own load tests on Cloud API as you might have done for your own on-premises installation. You can also refer to our performance comparison to understand more details around how the on-premise and Cloud APIs compare.
Migrating between the on-premises and Cloud APIs is seamless, and can be done bidirectionally. See migration details for more information.
請查看我們的「 WhatsApp Business API 狀態頁面 」,瞭解雲端 API 特定的可觀察性指標。
可用性每天更新一次。
在某些情況下,系統可能會自動錯誤地將某些用戶錯誤計入停機時間。在這些情況下,我們會在一週內進行詳細分析後,將停機時間覆寫為執行時間。
在某些情況下,可能不會自動追蹤可用性停機時間:
在此之後允許進入我們系統之前出現的任何問題,都會顯示為錯誤或未成功。此外,在第一次嘗試發出 Webhook 之後遇到的問題也會繼續重試,直到成功傳遞到 Webhook 端點為止。
手動偵測後反映在可用性主控板中的其他情況包括(非系統錯誤):
在這兩種情況下,WhatsApp 都會在事後偵測並解決這些問題,接近即時,但非即時。
我們目前並未提供適用於運作時間和/或延遲的產品服務水準合約。
We will have disaster recovery and data replication across multiple regions. The expected downtime would be within our SLA and usually in the order of less than a minute to less than five minutes.