문서가 업데이트되었습니다.
한국어로 번역이 아직 완료되지 않았습니다.
영어 업데이트됨: 4월 25일
한국어 업데이트됨: 3월 6일

Support

Troubleshooting

Message Not Delivered

The following scenarios can cause a message to appear as sent but not delivered. For many of these reasons, we will not disclose the underlying cause of the error, due to privacy and policy reasons.

  • The customer did not come online during the 30 day window where we hold messages for offline customers.
  • The customer has blocked the business phone number, or another business phone number owned by the business.
  • The customer is in a restricted or sanctioned country.

In some scenarios, the API returns an error code with an error message describing the nature of the error. Example scenarios:

  • Invalid request parameters
  • Integrity errors
  • The customer has not accepted our new Terms of Service and Privacy Policy. Please send your end user this link https://wa.me/tos/20210210 to accept the latest Terms of Service.
  • The customer is using an old version of WhatsApp. Customers should use the following version or greater:
    • Android: 2.21.15.15
    • SMBA: 2.21.15.15
    • iOS: 2.21.170.4
    • SMBI: 2.21.170.4
    • KaiOS: 2.2130.10
    • Web: 2.2132.6
  • The customer is part of an experiment group.
  • The message was not delivered to create a high quality user experience. See Per-User Marketing Template Message Limits.

Possible Solutions

Using a non-WhatsApp communication method, ask the WhatsApp user to:

  • confirm that they can actually send a message to your WhatsApp business phone number(s)
  • confirm that none of your WhatsApp business phone numbers are in their list of blocked numbers (Settings > Privacy > Blocked or Blocked contacts)
  • confirm that they have accepted our latest Terms of Service (Settings > Help, or Settings > Application information will prompt them to accept the latest terms/policies if they haven't done so already)
  • update to the latest version of the WhatsApp client

Country Restrictions

Businesses in Cuba, Iran, North Korea, Syria, and three sanctioned regions in Ukraine (Crimea, Donetsk, Luhansk) are not eligible to use the WhatsApp Business Platform.

WhatsApp Messenger (WhatsApp) and WhatsApp Business app users in Cuba, Iran, North Korea, Syria, and three sanctioned regions in Ukraine (Crimea, Donetsk, Luhansk) are not eligible to receive messages sent via the WhatsApp Business Platform.

Businesses in Turkey can use the platform, but messages sent via Cloud API to WhatsApp users who have a Turkish country calling code will not be delivered, and messages sent from these users to a business phone number registered for use with Cloud API will not be delivered.

Webhooks

Conflicting Message Delivery Status

In rare cases, the same message may trigger both success and failure message status update webhooks. For example, a message may trigger message webhooks with "status":"delivered" and another webhook with "status":"failed". This can happen when a customer is logged in to WhatsApp on multiple devices and the message is successfully delivered to one device but not the other. Any message that triggers a "delivered" message status webhook has been delivered to at least one of the user's devices.

Error Code 2 - API Service

When we update the API, you may experience up to 5 minutes of downtime. During this period of time, the service is unavailable. We try to make these updates with minimal disruption to businesses, but you may end up being affected

How To Debug

We suggest that you wait 5 minutes and try to make the API call again.

Authentication and Authorization Errors

These errors are returned when there was a problem with the access token you are using for the API call.

How To Debug

You can directly paste the access token you are using into the Access Token Debugger. Then, check if you have selected the whatsapp_business_management and whatsapp_business_messaging permissions.

If your token doesn’t have access to the permissions, you need to generate a new one. While generating the token, make sure to select:

  • The Meta app you are using for the API calls
  • The following permissions: whatsapp_business_management and whatsapp_business_messaging

FAQs

General FAQs

We expect Cloud API to provide the same key features as the On-Premises API soon, including user change notifications and sticker pack management. Our goal is for the Cloud API to become the preferred platform for new features.

We will release updates monthly with new features and improvements. There is no work required to access these features - the Cloud API updates automatically.

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.

No, we will continue to provide the On-Premises API for now. See On-Premises API for information.

No, there is no difference in messaging prices between the Cloud API and the On-Premises API. Access to Cloud API is free, and we expect it to generate additional cost savings for developers. The two types of cost savings for the Cloud API are 1) set up cost (including server or external cloud provider cost), 2) ongoing cost of maintenance (including engineering time for API upgrades).

A Solution Partner can select which setup a given client should use. We recommend that the majority of clients use the Cloud API for ease of implementation and maintenance. Solution Partners can also continue to maintain integration with the On-Premises 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.

Technical Implementation FAQs

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.

Reliability FAQs

가능한 일정은 하루에 한 번 업데이트됩니다.

특정 사용자 오류가 자동으로 가동 중지 시간에 잘못 반영되는 경우가 있을 수 있습니다. 이런 경우에는 일주일 안에 자세한 분석을 거친 후 가동 중지 시간을 가동 시간으로 재정의합니다.

글로벌 가용성에 영향을 미치지 않는 이슈가 있을 수 있습니다. 이와 같은 경우, WhatsApp Business API 상태 페이지는 글로벌 가용성에 영향을 미치지 않는 가동 중단을 반영한 상태를 표시합니다. 심층 조사를 위해 기술 지원 티켓을 제출해 주세요.

가용성에서 가동 중지 시간이 자동으로 추적되지 않는 경우는 다음과 같습니다.

  • 요청이 그래프 API 계층(첫 번째 계층)에 도달하기 전에 실패하는 네트워크 이슈.
  • 발송되는 Webhooks가 비즈니스의 Webhooks 엔드포인트에 도달하지 못하는 네트워크 이슈.

이 시점 이후 WhatsApp 시스템으로 들어오기 전에 나타나는 모든 이슈는 오류 또는 성공 실패로 표시됩니다. 첫 번째 Webhooks 전송 시도 이후에 이슈가 발생하는 경우에도 Webhooks가 Webhooks 엔드포인트로 전달될 때까지 계속 재시도합니다.

(시스템 오류가 아니라) 수동 감지 이후 가용성 대시보드에 반영되는 나머지 사례는 다음과 같습니다.

  • 정상적인 요청이 인증 또는 승인에 실패했는지 결정하는 Meta 인증 이슈(예: 인증 토큰(보안 라이브러리)).
  • 정상적인 요청을 거부하는 검증.

두 가지 경우 모두 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.