以下のシナリオでは、メッセージが送信済みであっても配信されていないように見える場合があります。プライバシーとポリシー上の理由から、Metaがこのエラーの根本原因を開示することはありません。
シナリオによっては、APIはエラーコードとエラーの性質を示すエラーメッセージを返します。シナリオの例:
WhatsApp以外の通信手段を利用して、WhatsAppユーザーに次のことを依頼してください。
キューバ、イラン、北朝鮮、シリア、およびウクライナの3地域(クリミア、ドネツク、ルハンシク)にあるビジネスは、WhatsApp Businessプラットフォームを使用することができません。
キューバ、イラン、北朝鮮、シリア、およびウクライナの3地域(クリミア、ドネツク、ルハンシク)にいるWhatsApp Messenger (WhatsApp)およびWhatsApp Businessのアプリユーザーは、WhatsApp Businessプラットフォーム経由で送信されたメッセージを受信できません。
2024年5月15日をもって、トルコにおけるクラウドAPIビジネスメッセージの利用制限がなくなりました。クラウドAPIビジネスは、トルコの電話番号を使って会話を開始したりWhatsAppユーザーからのメッセージを受信できるようになりました。
まれに、同じメッセージが成功と失敗の両方のメッセージステータス更新情報Webhooksをトリガーする場合があります。例えば、あるメッセージが、メッセージWebhooksを"status":"delivered"
でトリガーし、別のWebhooksを"status":"failed"
でトリガーする場合があります。これは、顧客が複数のデバイスのWhatsAppにログインしていて、メッセージが1つのデバイスに正しく送信され、もう一方のデバイスには送信されなかったときに起きる場合があります。"delivered"
メッセージステータスWebhooksをトリガーするメッセージはいずれも、少なくとも1つのユーザーのデバイスに配信されています。
2
- APIサービスMetaが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.
Metaの WhatsApp Business APIステータスページ にアクセスして、クラウドAPI固有の観測可能な指標をご覧ください。
詳しくは APIステータスページ を参照してください。
利用可能数は1日1回更新されます。
特定のユーザーエラーが間違って自動的にダウンタイムに計上される状況などが考えられます。このような状況では、1週間以内に詳細な分析をした上で、ダウンタイムをアップタイムに上書きします。
利用可能状況のダウンタイムが自動的にトラッキングされないケースとして、次のようなものがあります。
このポイント以降、システムへの統合許可が出される前に表面化するあらゆる問題は、エラーもしくは成功しなかったとして表示されます。また、Webhook発行を最初に試みた後で問題が発生した場合、Webhookのエンドポイントへの配信が成功するまで再試行が続けられます。
手動検出後に利用可能状況ダッシュボードに反映されるその他のケース(システムエラーではない)は、以下のとおりです。
どちらの場合も、問題が発生後、ほぼリアルタイムで(完全なリアルタイムではない)WhatsAppによって検出されます。
今のところ、稼働時間または遅延(あるいはその両方)について商業的に利用可能な製品サービス品質保証(SLA)は提供していません。
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.