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

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

Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.

Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.

Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Пошаговое решение
Отмечайте выполненные проверки. Отметки действуют до перезагрузки страницы.

Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko. 
Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko.
Развилка результата
Полная формулировка из статьи
Критерий результата: Повтор того же входящего изменения не отправляет второе сообщение и не повторяет действие, а новое допустимое изменение того же заказа проходит. После перезапуска поведение сохраняется. В журнале различаются полученное событие, пропуск повтора и выполненная обработка. Передача специалисту: Передайте поставщику один воспроизводимый пример: время с часовым поясом, используемый метод, версии компонентов и обезличенные запрос с ответом. Добавьте результат каждого шага и ожидаемое поведение. Не передавайте секреты в обычном журнале; укажите correlationId, если он получен.
Как понять, что проблема решена
Повтор того же входящего изменения не отправляет второе сообщение и не повторяет действие, а новое допустимое изменение того же заказа проходит. После перезапуска поведение сохраняется. В журнале различаются полученное событие, пропуск повтора и выполненная обработка.
Как снизить риск повторения
Делайте обработчики устойчивыми к повтору и проверяйте конкурентный запуск. Храните сведения о выполнении в соответствии с назначением события. Не заменяйте потерянный контроль бесконечным хранением всего заказа в оперативной памяти.
Если проблема осталась
Передайте поставщику один воспроизводимый пример: время с часовым поясом, используемый метод, версии компонентов и обезличенные запрос с ответом. Добавьте результат каждого шага и ожидаемое поведение. Не передавайте секреты в обычном журнале; укажите correlationId, если он получен.
Что передать в поддержку
Скопируйте шаблон и заполните его без паролей, API-ключей, данных карт и сведений о гостях.
Проблема: Вебхуки iiko приходят повторно: как убрать дубли обработки Версия и компонент iiko: Ресторан / рабочее место: Время сбоя и часовой пояс: Точный текст сообщения: Что ожидалось / что произошло: Какие проверки выполнены: Результат каждой проверки: Идентификатор операции (если допустимо):
Где помогает Menu 360
В интеграции Menu 360 с iiko автоматические допродажи должны относиться к одному составу заказа. Повтор уведомления не должен повторно добавлять предложенный десерт или отправлять гостю лишнее подтверждение. Цены задаются в самом Menu 360. После ремонта обработчика проверьте повтор события и отдельное новое изменение заказа.
Вопросы и ответы
Нужно игнорировать все события уже известного заказа?
Нет. Тогда потеряются следующие изменения состава или статуса. Защита от повтора должна различать действие и новое состояние, а не запрещать любую дальнейшую работу с объектом.
Достаточно ответить 200 в самом начале?
Ответ должен означать, что событие надёжно принято по выбранной архитектуре. Если подтверждать до сохранения, сбой процесса может потерять данные. Согласуйте устойчивый приём и отдельную обработку, а затем контролируйте оба этапа.
Источники и применимость
Официальная документация служит основой проверки возможностей iiko. Последовательность диагностики и контрольные примеры разработаны редакцией Menu 360; это не подтверждение ошибки именно в вашей конфигурации.