MENU 360
Интеграции и API · ПОШАГОВАЯ ИНСТРУКЦИЯ

Вебхуки iiko приходят повторно: как убрать дубли обработки

Чтение: 4 мин.Редакция: 21 октября 2026

Два похожих вебхука не обязательно означают два заказа. Это могут быть повторная доставка одного сообщения, два изменения одного объекта или двойная обработка внутри приложения. Разберите входящие события до изменений кассы: борьба с ними через удаление заказов может повредить корректную историю.

Область применимости

Инструкция для администратора и разработчика внешнего сервиса. Это последовательная диагностика, а не обещание единственной причины по сообщению об ошибке. Рабочие доступы, платежи и кассовые документы не меняйте ради проверки. Сначала сохраните обезличенный пример и уточните используемую версию интеграции.

Как проявляется проблема

  • На одно изменение приходит несколько уведомлений.
  • Гость получает одинаковые сообщения повторно.

Что проверить сначала

  • Приёмник не подтверждает успешный приём.
  • Программа выполняет действие повторно после перезапуска.
  • Разные изменения одного объекта ошибочно считаются дублями.

Быстрая диагностика

Сравните свой симптом с проверкой и возможным результатом.
Что наблюдаемЧто проверитьКак понять результат
Похожие уведомленияСравнить объекты, времена и содержимое изменений.Разделить повтор доставки и новое состояние.
Гость получил два сообщенияПроверить ответ приёмника и фиксацию действия.Найти этап между выполнением и подтверждением.
После перезапуска дублиПроверить устойчивость учёта обработанного действия.Память процесса заменить согласованным устойчивым учётом.
Графическая проверка

Три точки наблюдения

Три точки наблюденияТри проверки из текста. Это диагностические наблюдения, не вымышленные элементы интерфейса. Сравнить объекты, времена и содержимое изменений. Проверить ответ приёмника и фиксацию действия. Проверить устойчивость учёта обработанного действия.1Сравнить объекты,времена исодержимоеизменений2Проверить ответприёмника ификсацию действия3Проверить учётобработанныхсобытий
Лупы обозначают предметы и данные для проверки. Подписи кратко передают содержание диагностики; полные формулировки и ограничения приведены в статье.
Полная формулировка из статьи

Сравнить объекты, времена и содержимое изменений. Проверить ответ приёмника и фиксацию действия. Проверить устойчивость учёта обработанного действия.

Менеджер и официант обсуждают работу ресторана с планшетом
Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko.

Маршрут диагностики

Графическая проверка

Маршрут проверок

Маршрут проверокПоследовательность выбранных проверок из статьи. Это маршрут диагностики, а не гарантия исправления. Вебхуки iiko приходят повторно: как убрать дубли обработки1Зафиксируйте повторвебхука2Проверьте тела ивремя входящихсобытий4Сверьте ответобработчика и ключповтора6Подтвердите однодействие наповторное событие
На схеме — ключевые проверки. Выполняйте полную последовательность ниже: номера ведут к соответствующим шагам с условиями и ограничениями.
Полная формулировка из статьи

Шаг 1. Сохраните обезличенную последовательность входящих тел и время получения каждого. Отдельно запишите время события, объект и действие программы. Сравнение только по номеру заказа слишком грубое: один заказ законно меняется много раз. Сначала установите, повторено сообщение или пришло следующее изменение. Шаг 2. Проверьте ответ обработчика на каждое уведомление. Официальное руководство указывает ответ 200 для подтверждения; без него возможна повторная отправка. Измеряйте ответ фактически, включая прокси и ошибки приложения. Запись «отправлено» внутри обработчика не доказывает, что отправитель получил нужный HTTP-ответ. Шаг 4. Определите ключ повторной обработки по контракту и назначению. Нельзя автоматически считать correlationId уникальным ID любого события или запретить все дальнейшие события того же заказа. Для уведомления о конкретном переходе храните факт выполненного перехода; для обновления данных сравнивайте применимое состояние и последовательность. Шаг 6. На тестовом сценарии повторно подайте сохранённое безопасное событие в свой обработчик, затем следующее изменение того же объекта. Первое не должно удвоить побочное действие, второе должно обработаться. После перезапуска повторите проверку, чтобы убедиться, что защита хранится устойчиво, а не только в памяти процесса.

Скриншоты и фрагменты документации

Фрагмент OpenAPI для POST /api/1/webhooks/settings: метод.
Визуализация фрагмента OpenAPI · OpenAPI 3.0.1; info.version не задана
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Фрагмент OpenAPI для POST /api/1/webhooks/settings: параметры.
Визуализация фрагмента OpenAPI · OpenAPI 3.0.1; info.version не задана
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Фрагмент OpenAPI для EVENT DeliveryOrderUpdate payload: ответ.
Визуализация фрагмента OpenAPI · OpenAPI 3.0.1; info.version не задана
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.

Пошаговое решение

Отмечайте выполненные проверки. Отметки действуют до перезагрузки страницы.

  1. Менеджер проверяет рабочее подключение в ресторане
    Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko.
  2. Сотрудник проверяет состав заказа перед доставкой
    Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko.
Графическая проверка

Развилка результата

Развилка результатаСопоставьте результат с критерием статьи. Да — критерий подтвержден; нет — передайте диагностические данные специалисту. Критерий: Повтор того же входящего изменения не отправляет второе сообщение и не повторяет действие, а новое допустимое изменение того же заказа проходит. После перезапуска поведение сохраняется. В журнале различаются полученное событие, пропуск повтора и выполненная обработка. Поддержка: Передайте поставщику один воспроизводимый пример: время с часовым поясом, используемый метод, версии компонентов и обезличенные запрос с ответом. Добавьте результат каждого шага и ожидаемое поведение. Не передавайте секреты в обычном журнале; укажите correlationId, если он получен.Критерийвыполнен?ДаНетодно действиена повторноесобытиеПередайтеevent ID,время и ответобработчика
Ромб — самопроверка по критерию из статьи. Ветка «нет» ведет к подготовке обращения, а не к обещанному исправлению.
Полная формулировка из статьи

Критерий результата: Повтор того же входящего изменения не отправляет второе сообщение и не повторяет действие, а новое допустимое изменение того же заказа проходит. После перезапуска поведение сохраняется. В журнале различаются полученное событие, пропуск повтора и выполненная обработка. Передача специалисту: Передайте поставщику один воспроизводимый пример: время с часовым поясом, используемый метод, версии компонентов и обезличенные запрос с ответом. Добавьте результат каждого шага и ожидаемое поведение. Не передавайте секреты в обычном журнале; укажите correlationId, если он получен.

Как понять, что проблема решена

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

Как снизить риск повторения

Делайте обработчики устойчивыми к повтору и проверяйте конкурентный запуск. Храните сведения о выполнении в соответствии с назначением события. Не заменяйте потерянный контроль бесконечным хранением всего заказа в оперативной памяти.

Если проблема осталась

Передайте поставщику один воспроизводимый пример: время с часовым поясом, используемый метод, версии компонентов и обезличенные запрос с ответом. Добавьте результат каждого шага и ожидаемое поведение. Не передавайте секреты в обычном журнале; укажите correlationId, если он получен.

Что передать в поддержку

Скопируйте шаблон и заполните его без паролей, API-ключей, данных карт и сведений о гостях.

Проблема: Вебхуки iiko приходят повторно: как убрать дубли обработки
Версия и компонент iiko:
Ресторан / рабочее место:
Время сбоя и часовой пояс:
Точный текст сообщения:
Что ожидалось / что произошло:
Какие проверки выполнены:
Результат каждой проверки:
Идентификатор операции (если допустимо):

Где помогает Menu 360

В интеграции Menu 360 с iiko автоматические допродажи должны относиться к одному составу заказа. Повтор уведомления не должен повторно добавлять предложенный десерт или отправлять гостю лишнее подтверждение. Цены задаются в самом Menu 360. После ремонта обработчика проверьте повтор события и отдельное новое изменение заказа.

Интеграция Menu 360 с iiko · Автоматические допродажи

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

Нужно игнорировать все события уже известного заказа?

Нет. Тогда потеряются следующие изменения состава или статуса. Защита от повтора должна различать действие и новое состояние, а не запрещать любую дальнейшую работу с объектом.

Достаточно ответить 200 в самом начале?

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

Источники и применимость

Официальная документация служит основой проверки возможностей iiko. Последовательность диагностики и контрольные примеры разработаны редакцией Menu 360; это не подтверждение ошибки именно в вашей конфигурации.

Связанные инструкции