Для асинхронного изменения LaaS-заказа нужно отслеживать отдельную операцию. Успешный ответ на запрос статуса ещё не означает, что само изменение завершено.

Справка проверена 14 октября 2026 года. Это дата редакционной проверки, а не запуска функции. Руководство относится к действующим аккаунтам на поддерживаемых рынках платформы.

Храните операцию отдельно от заказа

Метод POST v1/businesses/{businessId}/operations возвращает состояния запущенных операций по их идентификаторам. Он относится к модели LaaS; документация отдельно отмечает недоступность для Market Yandex Go. Переносить этот механизм на произвольный FBS-заказ без соответствующего метода нельзя.

В запросе передают operationType и список operationIds. Среди типов есть изменение получателя, интервала доставки, срока хранения, отмена заказа и отмена возврата. Внутренний журнал полезно строить вокруг пары «операция — заказ»: один заказ может стать предметом разных действий, и его номер не заменяет идентификатор каждого из них.

Не смешивайте два уровня статуса

Общий status ответа сообщает результат обработки API-запроса. Внутри result.operations у каждой операции собственный status: IN_PROGRESS, DONE или FAILED. Первый означает выполнение, второй — успешное завершение, третий — ошибку. Технически удачное чтение состояния может вернуть всё ещё выполняющуюся операцию.

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

Как проверять очередь без повторного изменения

В одном запросе допускается от 1 до 100 уникальных идентификаторов; тип операции задаётся отдельно. Разделяйте очередь по кабинету и типу, затем сопоставляйте каждый ответ с сохранённым идентификатором. Такой порядок снижает риск приписать успешный результат соседнему заказу.

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

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

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

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