Если складская система переводит сразу несколько заказов Яндекс Маркета в готовность, она должна проверить результат каждой строки ответа. Метод orders/status-update возвращает updateStatus и, при ошибке, errorDetails по конкретному заказу. Успешное получение ответа не означает, что все заказы пакета перешли в нужное состояние. Документация проверена 19 октября 2026 года.

Отправляйте только допустимые переходы

В одном запросе допускается от одного до тридцати заказов. Метод работает с FBS, Экспрессом, DBS и LaaS, однако допустимый переход зависит от модели и текущего состояния заказа. Например, готовность FBS выражается сочетанием PROCESSING и READY_TO_SHIP, а не произвольной заменой общего статуса.

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

Разберите результат по идентификаторам

Для каждой строки ответа значение updateStatus сообщает, изменён ли статус. ERROR означает неуспех; пояснение находится в errorDetails. Сопоставляйте строки с исходными заказами по идентификатору, а не по позиции в массиве или общему количеству записей.

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

Не отмечайте отсутствующий в ответе заказ успешным по умолчанию. Такая ситуация требует дополнительной сверки. Для операционной работы полезен отдельный статус «результат не подтверждён»: он отличает неизвестный исход от явного отказа площадки и помогает выбрать следующий запрос.

Повторяйте только обоснованные действия

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

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

Для LaaS дополнительно учитывайте отложенное выполнение отдельных операций. Сценарий разбирается в инструкции о проверке результата операции LaaS. Нельзя переносить правила синхронной обработки одной модели на все остальные заказы только потому, что используется похожий ответ API.

Проверьте приёмку интеграции

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

Итоговый контроль — совпадение списка готовых заказов в учётной системе и подтверждённых состояний Маркета. Количество нажатий кнопки или зелёный сетевой запрос не заменяют эту сверку. Ответственный за смену получает понятный список исключений и может завершить работу до передачи отправлений перевозчику.