Skip to main content
Отправка запроса и доставка сообщения — это разные события. Успешный ответ API подтверждает результат запроса на данном этапе; он не гарантирует, что клиент получил или прочитал сообщение. Используйте статус сообщения YCloud и любые доступные сведения об ошибке, чтобы понять, что произошло.

​
Статусы исходящих сообщений

Ресурс исходящих сообщений WhatsApp в YCloud использует следующие статусы: Типичная успешная последовательность: accepted → sent → delivered → read. Не предполагайте, что ваше приложение получит каждое промежуточное обновление или что обновления придут именно в таком порядке.

​
Почему успешный запрос не означает окончательную доставку

При использовании эндпоинта с очередью YCloud принимает запрос и отправляет его асинхронно. При использовании прямого эндпоинта отправка в WhatsApp Business API происходит синхронно. Окончательная доставка в обоих случаях остается асинхронной. Подробные сведения о реализации см. в разделе Отправка сообщения WhatsApp. Если текущий статус по-прежнему accepted или sent, не отправляйте повторно один и тот же контент. Дополнительный запрос может привести к дублированию сообщения.

​
Отчеты о доставке и прочтении

Статус «Доставлено» означает, что сообщение дошло до устройства клиента. Это не означает, что клиент открыл диалог. Отчеты о прочтении доступны не всегда. Например, настройки отчетов о прочтении у клиента могут влиять на то, будет ли отправлено уведомление о прочтении. Отсутствие такого обновления не является доказательством того, что клиент проигнорировал сообщение. Определения статусов на стороне провайдера см. в справочнике Meta message status webhook reference.

​
Отслеживание одного и того же сообщения в разных системах

При устранении неполадок сохраняйте следующую информацию вместе: Не передавайте ключи API или лишнюю информацию о клиентах при отправке данных для устранения неполадок. Интеграции API могут получать вебхуки whatsapp.message.updated и запрашивать ресурс сообщения. См. раздел Рекомендации по обмену сообщениями в WhatsApp для настройки синхронизации и повторных попыток.

​
Анализ сообщений с ошибкой доставки

Начинайте анализ с возвращенной ошибки, а не только с названия статуса.
  • Проблема с шаблоном: убедитесь, что шаблон доступен, а его язык и параметры указаны верно.
  • Проблема с окном переписки: проверьте, требуется ли для сообщения открытое окно обслуживания клиентов.
  • Проблема с аккаунтом или номером: проверьте затронутый ресурс и его текущие ограничения.
  • Проблема с контентом или медиа: проверьте требования выбранного типа сообщений.
  • Контроль доставки: следуйте указаниям конкретной ошибки. Немедленные повторные попытки могут не снять ограничение платформы.
Недоставленное сообщение не означает, что клиент заблокировал ваш номер. Опирайтесь на фактические сведения об ошибке и избегайте предположений о действиях клиента, которые не были зафиксированы платформой. Сведения о контроле доставки на платформе см. в разделе Контроль качества и доставки. Информацию об уведомлениях о нарушениях см. в разделе Ограничения аккаунта и апелляции.

​
Оценка безопасности повторной отправки

Корректная запись сообщения связывает одно запланированное бизнес-действие с его запросами и результатами. Ваш внешний идентификатор (external reference) помогает сопоставлению, но не гарантирует идемпотентность API, если только эндпоинт явно не предоставляет такого поведения.

​
Пример задержки обновлений статуса

Ваша система получает delivered, а затем задержанное событие sent для того же сообщения. Не меняйте статус клиента обратно на «не доставлено». Сохраняйте временные метки событий и используйте модель состояний, устойчивую к дублирующим и нарушающим порядок обновлениям. Аналогично, отсутствие события read не означает ошибку отправки сообщения. Разделяйте следующие показатели:
  • Охват доставки: сообщения с подтверждением доставки.
  • Охват прочтений: сообщения с отчетом о прочтении.
  • Отклик клиента: фактический входящий ответ или взаимодействие.
  • Бизнес-конверсия: подтвержденное бронирование, покупка или успешная верификация в соответствующей системе.

​
Дальнейшие действия

​
Часто задаваемые вопросы

Такой вывод сделать нельзя. Отчеты о прочтении могут быть недоступны, в том числе если получатель их отключил. Учитывайте статусы «доставлено» и «прочитано» как раздельные метрики. Ни отсутствие отчета о прочтении, ни общая ошибка недоставки не указывают причину со стороны клиента и не доказывают блокировку.
Не сразу. Платформа могла уже принять запрос. Проверьте идентификатор сообщения, доступные логи и последующие события Webhook перед выполнением повторной отправки. Связывайте попытки с одним и тем же бизнес-действием и предусматривайте защиту от дубликатов; внешний идентификатор не гарантирует автоматическую идемпотентность эндпоинта.
Ограничение отображения и сбой доставки — это разные вещи. Проверьте фактическое направление, статус, тип сообщения и наличие ошибок. Для входящего контента следуйте руководству по неподдерживаемым сообщениям в Inbox; не делайте предположений о содержании и не считайте плейсхолдер неудачной исходящей отправкой.