Dans les scénarios suivants, un message peut apparaître comme envoyé, mais pas distribué : Pour des raisons de confidentialité et de respect des politiques, nous ne divulguerons pas la cause sous-jacente de cette erreur.
Dans certains scénarios, l’API renvoie un code d’erreur accompagné d’un message décrivant la nature de l’erreur. Exemples de scénarios :
Utiliser un moyen de communication autre que WhatsApp pour demander à l’utilisateur·ice WhatsApp de :
Les entreprises établies à Cuba, en Iran, en Corée du Nord, en Syrie et dans les trois régions sanctionnées en Ukraine (Crimée, Donetsk, Louhansk) ne sont pas autorisées à utiliser la plateforme WhatsApp Business.
Les utilisateur·ices de WhatsApp Messenger (WhatsApp) et de l’application WhatsApp Business résidant dans ces mêmes pays et régions ne peuvent pas recevoir de messages envoyés via la plateforme WhatsApp Business.
À compter du 15 mai 2024, la Turquie ne fait plus l’objet de restrictions concernant la messagerie professionnelle de l’API Cloud. Les entreprises utilisant l’API Cloud peuvent à présent lancer des conversations et recevoir des messages d’utilisateur·ices de WhatsApp ayant des numéros turcs.
Dans de rares cas, le même message peut déclencher les webhooks de mise à jour du statut de distribution à la fois comme ayant réussi et échoué. Par exemple, un même message peut déclencher des webhooks "status":"delivered"
et un autre webhook "status":"failed"
. Cela peut arriver lorsqu’un·e client·e est connecté·e à WhatsApp sur plusieurs appareils et que le message est bien distribué sur un appareil, mais pas sur l’autre. Si un message déclenche un webhook de statut "delivered"
, cela signifie qu’il a été distribué sur au moins un de ses appareils.
2
– API ServiceUne mise à jour de l’API peut engendrer un temps d’inactivité de 5 minutes. Pendant ce délai, le service est indisponible. Nous essayons de réaliser ces mises à jour avec un minimum de perturbation pour les entreprises, mais cela pourrait affecter votre activité.
Nous vous suggérons de patienter 5 minutes avant de réessayer l’appel API.
Ces erreurs sont renvoyées lorsque vous rencontrez un problème avec le token d’accès utilisé pour l’appel API.
Vous pouvez coller le token d’accès utilisé directement dans le Débogueur de token d’accès. Vérifiez ensuite si vous avez sélectionné les autorisations whatsapp_business_management
et whatsapp_business_messaging
.
Si votre token n’a pas accès aux autorisations, vous devez en générer un nouveau. Lorsque vous générez un token, veillez à sélectionner les éléments suivants :
whatsapp_business_management
et 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.
Consultez notre page Statut de l’API WhatsApp Business pour accéder à des indicateurs d’observation spécifiques de l’API Cloud.
Consultez la page de statut de l’API pour en savoir plus.
La disponibilité est mise à jour une fois par jour.
Dans certains cas, des erreurs des utilisateur·ices sont automatiquement comptabilisées à tort comme des temps d’inactivité. Après analyse poussée du problème, nous pouvons convertir le temps d’inactivité en temps d’activité. La rectification intervient sous une semaine.
Certains problèmes n’ont pas d’incidence sur notre disponibilité globale. La page de statut de l’API WhatsApp Business indiquera alors que des interruptions peuvent survenir, sans pour autant affecter notre disponibilité globale. Envoyez une demande à l’ Assistance directe pour obtenir plus d’informations.
Il existe des cas où les temps d’inactivité ne sont pas automatiquement suivis :
Après cela, tous les problèmes survenant avant l’admission dans notre système apparaîtront comme des erreurs ou des échecs. Les problèmes rencontrés après la première tentative d’émission du webhook entraîneront de nouveaux essais jusqu’à ce que le webhook soit effectivement distribué au point de terminaison du webhook.
Les autres cas présentés dans le tableau de bord des disponibilités après la détection manuelle (donc, non en tant qu’erreur système) sont :
Dans les deux cas, WhatsApp détecte ces problèmes et les prend en compte après leur survenue, pratiquement en temps réel.
Actuellement, nous ne proposons pas d’accords de niveau de service relatifs au temps d’activité et/ou à la latence pour nos produits.
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.