Уведомление о новом заказе стройте отдельно от учёта самого заказа: сначала надёжно примите событие, затем получите актуальные данные и поставьте сообщение сотруднику в очередь. Повтор события не должен создавать второй заказ или второй одинаковый сигнал. Начните с собственных тестовых заказов и закрытого служебного канала.
В сообщение обычно достаточно вынести магазин, внутреннюю ссылку и краткое состояние, согласованное для этой группы сотрудников. Адрес, телефон и полный состав персональных сведений не копируйте по умолчанию. Получатель должен открывать детали в системе с действующими правами; доступ к каналу не заменяет право на конкретный заказ.
Событие сообщает об изменении, а не хранит всю истину
Документация Яндекс Маркета предупреждает, что одно событие может породить несколько уведомлений и что состояние заказа к моменту чтения уже может отличаться. В инструкции получения заказов события сочетаются с запросом подробностей. Источники проверены 11 октября 2026 года. Политику сообщений и внутренний ключ обработки проектирует ваше приложение.
Условная цепочка приложения:
принятое событие
-> сохранённая запись обработки
-> актуальное чтение заказа
-> разрешённый получатель
-> очередь сообщения
-> подтверждение или неизвестный исход отправкиНе удерживайте ответ площадке до окончания отправки в рабочий чат. Надёжно сохранённое событие можно обработать отдельной задачей. Конкретное подтверждение приёма и проверку подлинности выполняйте по документации площадки. Здесь нет универсального webhook-пароля, который можно одинаково вставить в любой обработчик.
Когда два сигнала считаются одним
| Случай | Решение обработки | Что видит сотрудник |
|---|---|---|
| Повтор того же события | Повторное выполнение без новой записи | Один согласованный сигнал |
| Новый статус того же заказа | Отдельное изменение по правилам | Обновление или новый нужный сигнал |
| Сбой получения деталей | Отложить чтение с контролируемым повтором | Не выдуманный статус |
| Неизвестен результат сообщения | Проверка или отмеченный повтор | Понятная причина возможного дубля |
Ключ события выбирайте по доступному идентификатору площадки и области магазина. Если отдельного ID события нет, разработайте правило на реальных полях документации и испытайте законные повторные изменения. Один order_id для всего жизненного цикла может случайно подавить важное сообщение об отмене; случайный ID каждого запроса, наоборот, пропустит все дубли.
Увольнение сотрудника меняет адресатов очереди
Перед доставкой снова проверьте, что канал и получатели разрешены для этого магазина. Старое задание может дождаться выполнения после перевода сотрудника в другой отдел. Получателей нельзя фиксировать бессрочно только в момент события. Для общих каналов определите, какие магазины и какие поля им разрешено видеть, и предусмотрите отключение маршрута.
- Тестовый заказ магазина A не попадает в канал магазина B.
- Отключённый маршрут не отправляет накопленные сообщения.
- В текст не попадают токены, адреса API с секретами и личные контакты клиента.
- Ссылка требует штатного входа и проверяет доступ к заказу.
Доставка сообщения имеет собственную неопределённость
Если отправка закончилась тайм-аутом, сообщение могло дойти. Сохраните неизвестный исход и используйте возможности выбранного канала для выяснения результата. Когда надёжной проверки нет, заранее согласуйте допустимость отмеченного повторного оповещения. Обещание «ровно одно сообщение» без поддержки канала создаёт ложное ожидание.
Недоставленное оповещение не должно удалять заказ из учётной системы. Отслеживайте возраст очереди и последнюю подтверждённую доставку отдельно от состояния заказов. Для сверки пропущенных событий используйте разрешённое чтение с учётом правил площадки; не отправляйте заново все старые заказы как новые только из-за перезапуска обработчика.
- Повторить одно тестовое событие и проверить число сообщений.
- Изменить статус тестового заказа: новое разрешённое изменение не подавлено.
- Отключить получателя перед выполнением очереди.
- Имитировать неизвестный исход отправки и проверить принятую политику повтора.
Для настройки оповещения подготовьте карту магазин → группа сотрудников, минимальный состав сообщения и правило спорной доставки. Такой проект даёт сотруднику полезный сигнал и оставляет заказ в надёжной системе учёта даже тогда, когда рабочий чат временно недоступен.