← Все статьи
Руководство

Очистка и удаление чата WhatsApp: синхронизация через webhook

Очистка чата WhatsApp удаляет его локальную историю, но сохраняет сам чат. Удаление чата — отдельное действие со списком чатов. В UnifyPort события conversation.cleared и conversation.deleted сообщают об этих изменениях для подключённого аккаунта обмена сообщениями. Ни одно из них не означает удаления сообщений у всех участников. В общем входящем ящике нужно разделять видимость истории и видимость диалога, а собственные копии обрабатывать по явно определённым правилам.

Главное

  • Это локальные изменения аккаунта, а не команды удалить сообщения клиента.
  • Целевой чат задаёт data.conversation.id, а не верхнеуровневый id события.
  • delete_media описывает удаление локальных медиа, но не очистку вашего хранилища или CRM.
  • Запрет на восстановление старой истории не должен означать вечный запрет на новые сообщения.

Очистка чата, удаление чата или отзыв сообщения?

В инструкции WhatsApp по очистке указано: очистка не убирает чат из списка и не выводит вас из группы. Инструкция по удалению рассматривает другое действие и говорит, что перед удалением группового чата нужно выйти из группы. Не превращайте ни одну из этих операций в универсальную команду уничтожить все данные во всех интеграциях.

СобытиеДокументированный смыслРекомендуемая реакция приложения
conversation.clearedПодключённый аккаунт очистил локальную историю; удалённый диалог и членство в группе не изменилисьСохранить карточку диалога, ограничить показ соответствующей истории по правилам продукта
conversation.deletedАккаунт удалил диалог локальноУбрать его из обычного зеркального списка; оставить только разрешённые метаданные для сверки
message.deletedУдалено или отозвано отдельное сообщениеНайти конкретное сообщение, а не весь чат
conversation.updatedИзменена локальная настройка чатаОбновить переданную настройку, не делать вывод об удалении истории

Последний столбец — рекомендации по архитектуре, а не автоматические действия UnifyPort. Если требуется отозвать отправленное сообщение, используйте руководство по редактированию, отзыву и локальному скрытию. Событие удаления диалога не является подтверждением запроса на отзыв.

Разбирайте событие диалога, а не сообщения

В справочниках conversation.cleared и conversation.deleted есть цель операции и delete_media. В них нет списка затронутых сообщений или документированной точной границы истории.

Ниже пример с документированными полями и вымышленными идентификаторами, а не запись реального трафика:

{
  "id": "evt_c4d0b7a2e5",
  "type": "conversation.cleared",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-10-29T08:15:00Z",
  "data": {
    "conversation": {
      "id": "8600000000000@s.whatsapp.net",
      "type": "user"
    },
    "delete_media": true,
    "event": { "kind": "conversation_cleared" }
  }
}

Ищите локальную запись по рабочему пространству, провайдеру, account_id и data.conversation.id вместе. Сохраняйте полученный идентификатор: не собирайте его из номера телефона и не объединяйте чаты по одинаковому названию. В этой ветке не требуйте data.message.id: событие относится к диалогу.

Матрица событий провайдеров сейчас сопоставляет оба события с whatsapp, но не с отдельным whatsapp-protocol и не со всеми остальными каналами. Это поддержка парсера, а не гарантия появления событий для каждого аккаунта или окружения вышестоящего сервиса.

Разделите три вида состояния приложения

Сначала определите обещания продукта. Зеркальный входящий ящик может скрывать локальную историю вслед за аккаунтом, тогда как отдельный архив обращений может подчиняться другим правилам хранения. Объясните это операторам: нативная очистка не должна молча означать ни «ничего не произошло», ни «удалить все деловые записи».

Храните отдельно:

  1. Видимость диалога в списке: показывается ли он в зеркальном интерфейсе.
  2. Видимость истории и статус очистки: какой старый контент скрыт и какие ваши копии ещё требуют обработки.
  3. Приём будущих сообщений: при каких условиях новая активность возвращает диалог в список, не возвращая старую историю.

Это локальные концепции, а не дополнительные поля webhook. Оставляйте минимальный маркер с областью действия и решением по очистке. Если удалить все сведения об идентичности диалога, запоздалый пакет истории может заново создать видимые записи.

Для обоих типов событий соблюдайте контракт доставки webhook: задайте signing_secret, проверяйте HMAC-SHA256 от X-Device-Timestamp, точки и исходного тела запроса, а также допустимую давность timestamp. В одной локальной транзакции выполните дедупликацию обычного события, сохраните изменение видимости и поставьте очистку в очередь. Возвращайте 2xx после надёжного сохранения, не дожидаясь всех внешних систем.

Не позволяйте загрузке истории отменять принятое решение

Порядок доставки не гарантирован. occurred_at сообщает время события, но контракт очистки и удаления не определяет его как точную границу всех затронутых сообщений. Время поступления HTTP-запроса тоже не доказывает новизну содержимого.

Последующий входРекомендуемое поведение, пока действует скрытие
Повтор того же события очистки или удаленияСохранить решение, продолжить незавершённую очистку
Исторический пакет со скрытым содержимымНе публиковать его снова автоматически
Живое событие с уже скрытым ID сообщенияСохранить скрытие
Сообщение выглядит новым, но его связь с очисткой неяснаОтложить автоматический ответ и проверить область действия
Подтверждённая новая активностьОткрыть диалог по правилам продукта, не восстанавливая старую историю

Известные ID защищают уже сохранённый контент, но не позволяют распознать старые сообщения, которые приложение ещё не получало. Без надёжной границы выбирайте явную проверку или консервативное скрытие, а не обещайте идеальное восстановление хронологии. Новый ID события сам по себе не означает новое содержимое сообщения.

Если интерфейс позволяет загружать прошлые сообщения, применяйте эту политику в процессе слияния из руководства по истории WhatsApp по запросу. Исторические пакеты объединяются по дочерним сообщениям: дедупликация только по верхнеуровневому ID события может отбросить корректные части. Загрузка истории не должна неявно сбрасывать решение об очистке.

Медиа и приёмочные проверки

delete_media=true означает, что локальные медиа тоже удалены или очищены. Это не подтверждение удаления скачанных вложений, поискового индекса, контекста ИИ или пересланных копий. Значение false также не разрешает бессрочно хранить всё. Применяйте раскрытые пользователям правила хранения и доступа, отслеживая завершение очистки отдельно от подтверждения webhook.

Проверьте на аккаунтах под вашим контролем:

  • После очистки карточка диалога остаётся, но скрытое содержимое не находится поиском.
  • После удаления чат исчезает из зеркального списка без блокировки контакта или запроса на выход из группы.
  • Старый пакет истории или повтор события не восстанавливает контент.
  • Подтверждённая новая активность открывает диалог без старой истории.
  • Ошибка очистки медиа отображается как незавершённая работа, а не полное удаление.

Это предлагаемые тесты, не опубликованные результаты. UnifyPort — неофициальный интерфейс без гарантированного повтора пропущенных событий и без REST API чтения истории сообщений. Отсутствие события не доказывает отсутствие локального изменения.

Вопросы и ответы

conversation.deleted удаляет сообщения у собеседника?

Нет. Документация описывает локальное удаление диалога подключённым аккаунтом, а не удаление у всех.

conversation.cleared означает выход из группы?

Нет. Документация прямо указывает, что членство в группе сохраняется.

Можно ли на основе этих событий сделать кнопку вызова API очистки чата?

События описывают наблюдения, а не исходящие операции очистки и удаления. Не выводите существование endpoint из имени события.

Следующий шаг и источники

Начните со справочника conversation.cleared. Определите правила видимости, хранения и повторного открытия до подключения необратимой очистки.

Источники проверены 2026-10-29:

UnifyPort API

Превратите интеграцию сообщений в стабильный продуктовый pipeline.

Начните с отправки через единый API, затем возвращайте входящие сообщения в бизнес-систему стандартными событиями.