다음과 같은 경우 메시지가 전송되었지만 전달되지 않은 것으로 표시될 수 있습니다. 개인정보 보호 및 정책 등 여러 가지 이유로 인해 오류의 기본 원인을 공개하지 않습니다.
일부 시나리오에서는 API가 오류의 성격을 설명하는 오류 메시지와 함께 오류 코드를 반환합니다. 시나리오 예시는 다음과 같습니다.
WhatsApp 외의 다른 통신 수단을 사용하는 경우 WhatsApp 사용자에게 다음 작업을 요청하세요.
쿠바, 이란, 북한, 시리아 그리고 우크라이나의 3개 제재 지역(크림반도, 도네츠크, 루한시크)에 있는 비즈니스는 WhatsApp Business 플랫폼을 사용할 수 없습니다.
쿠바, 이란, 북한, 시리아 그리고 우크라이나의 3개 제재 지역(크림반도, 도네츠크, 루한시크)에 있는 WhatsApp Messenger(WhatsApp) 및 WhatsApp Business 앱 사용자는 WhatsApp Business 플랫폼을 통해 전송된 메시지를 받을 수 없습니다.
2024년 5월 15일부터 튀르키예에서 클라우드 API 비즈니스 메시지가 더 이상 제한되지 않습니다. 이제 클라우드 API 비즈니스는 튀르키예 전화번호로 대화를 시작하고 WhatsApp 사용자에게 메시지를 받을 수 있습니다.
드물게 동일한 메시지가 성공과 실패 메시지 상태 업데이트 Webhooks를 트리거할 수 있습니다. 예를 들어 하나의 메시지가 "status":"delivered"
를 포함한 메시지 Webhooks를 트리거하고 "status":"failed"
를 포함한 메시지 Webhooks도 트리거할 수 있습니다. 이 문제는 고객이 여러 기기에서 WhatsApp에 로그인하고 메시지가 한 기기에는 성공적으로 전달되었지만 다른 기기에는 전달되지 못한 경우에 발생할 수 있습니다. "delivered"
메시지 상태 Webhooks를 트리거하는 메시지는 하나 이상의 사용자 기기에 전달된 상태입니다.
2
- API 서비스API를 업데이트할 때 가동 중지 시간이 최대 5분간 발생할 수 있습니다. 이 시간에는 서비스를 사용할 수 없습니다. Meta에서는 비즈니스 중단을 최소화하여 업데이트하려고 최선을 다하고 있지만 어쩔 수 없이 영향을 받게 될 수도 있습니다.
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.
클라우드 API의 특정 관찰 가능성 지표는 WhatsApp Business API 상태 페이지 를 참조하세요.
자세한 내용은 API 상태 페이지 를 참조하세요.
가능한 일정은 하루에 한 번 업데이트됩니다.
특정 사용자 오류가 자동으로 가동 중지 시간에 잘못 반영되는 경우가 있을 수 있습니다. 이런 경우에는 일주일 안에 자세한 분석을 거친 후 가동 중지 시간을 가동 시간으로 재정의합니다.
가용성에서 가동 중지 시간이 자동으로 추적되지 않는 경우는 다음과 같습니다.
이 시점 이후 WhatsApp 시스템으로 들어오기 전에 나타나는 모든 이슈는 오류 또는 성공 실패로 표시됩니다. 첫 번째 Webhooks 전송 시도 이후에 이슈가 발생하는 경우에도 Webhooks가 Webhooks 엔드포인트로 전달될 때까지 계속 재시도합니다.
(시스템 오류가 아니라) 수동 감지 이후 가용성 대시보드에 반영되는 나머지 사례는 다음과 같습니다.
두 가지 경우 모두 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.