Обновление Seller API от 15 октября 2026 года затрагивает сведения о курьерском возврате, проверку доступных способов и настройки склада FBS. Интеграции нужно проверить все три участка: успешно загруженный список возвратов ещё не подтверждает корректную настройку их получения.

Какие части обмена затронуло обновление

В ответе метода /v1/returns/list появился параметр returns.courier_delivery. Метод /v1/warehouse/fbs/return-mile/check получил параметры is_courier_return_mile_available и is_dropoff_return_mile_available. В запросы /v1/warehouse/fbs/create и /v1/warehouse/fbs/first-mile/update добавили courier_return_warehouse_info.

Это описание изменений обмена данными. Само появление полей не означает, что любой склад автоматически подключён к курьерским возвратам. Объявление также не устанавливает новый тариф или срок приезда курьера. Такие условия нельзя выводить из технического названия параметра: для конкретного склада необходимо проверить действующие настройки и доступный способ получения.

Как проверить загрузку возвратов в учётную систему

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

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

Как связать способ получения с нужным складом

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

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

Что считать завершённой проверкой

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

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

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