После остановки интеграции недостаточно загрузить только новые заказы: за время сбоя могли измениться уже известные. В API Яндекс Маркета выборка по датам доставки и выборка по датам изменения задаются разными фильтрами. Это различие определяет, какие операции попадут в восстановленный рабочий список.

Не подменять дату доставки датой изменения

Для получения заказов используется business orders. Фильтры fromDate и toDate относятся к диапазону дат доставки, а updatedAtFrom и updatedAtTo — к заказам с изменениями. Если требуется восстановить события пропущенного промежутка, нельзя автоматически считать, что диапазон доставки найдёт те же записи.

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

Уведомление — повод получить детали

Официальная инструкция рекомендует API-уведомления: после события нужно запросить подробности заказа через business orders. Сам факт прихода сигнала не заменяет актуальные данные о составе и состоянии. Поэтому очередь событий и таблица заказов должны быть связаны, но не считаться одним и тем же объектом.

Если используется регулярный опрос, документация указывает интервалы: для Экспресса каждые 10–15 минут, для FBS и DBS не реже одного раза в час. Эти интервалы не являются гарантией допустимого опоздания при сборке конкретного заказа. Операционные сроки нужно соблюдать отдельно, исходя из его данных и выбранной модели.

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

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

На приёмке выберите несколько заказов, существовавших до сбоя, и проверьте их изменения после восстановления. Отдельно проверьте новый заказ, появившийся в пропущенное время. Такой набор выявляет две разные ошибки: потерю новых записей и сохранение устаревшего состояния старых.

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

Завершённое восстановление подтверждается совпадением с кабинетом по выбранным заказам и отсутствием повторных операционных действий. Зелёный статус вебхука или успешный HTTP-ответ сам по себе полноту восстановленного периода не доказывает.