Сбой приёмника API-уведомлений способен оставить магазин без оперативных событий, хотя продажи продолжаются. Для Яндекс Маркета важно контролировать не только доступность адреса, но и правильность ответа обработчика. Редакция проверила порядок 12 октября 2026 года; это руководство по эксплуатации интеграции.

Проверьте адрес и транспорт

Приёмнику нужен HTTPS с сертификатом доверенного центра; самоподписанный сертификат не подходит. Источник запроса следует проверять по правилам документации, включая разрешённые адреса. Тестовый PING требует ответа в течение секунды, обычное уведомление — десяти секунд.

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

Отвечайте по смыслу ошибки

Успешному приёму соответствует HTTP 200, некорректному входящему сообщению — 400, собственной технической ошибке обработчика — 500. Не возвращайте успешный ответ только ради зелёного индикатора, если событие нигде не сохранено: повторная доставка тогда не решит потерю.

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

Учитывайте остановку очереди

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

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

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

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

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