Для чтения заказов Яндекс Маркета старый GET списка магазина нужно заменить на POST списка кабинета. Простая замена HTTP-метода не завершает переход: меняются путь, область выборки и расположение фильтров.

Практическое руководство по документации, проверенной 27 октября 2026 года. Эта дата обозначает проверку требований, а не новое объявление Маркета.

Какие вызовы найти в интеграции

Устаревший путь — GET /v2/campaigns/{campaignId}/orders. По справке он начнёт работать нестабильно с 18 января 2027 года и будет отключён 12 апреля. Замена — POST /v1/businesses/{businessId}/orders.

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

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

Сохранить правильный охват магазинов

Раньше магазин задавался через campaignId в пути. Новый запрос использует businessId, а список campaignIds находится в JSON-теле. Различие уровней разобрано в инструкции по идентификаторам кабинета и магазина.

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

Перенести фильтры по схеме нового метода

В JSON-теле новый объект dates содержит creationDateFrom/creationDateTo для оформления, shipmentDateFrom/shipmentDateTo для отгрузки и updateDateFrom/updateDateTo для обновления. Для календарных дат схема использует ГГГГ-ММ-ДД. Пагинация остаётся в параметрах запроса pageToken и limit; следующая страница определяется nextPageToken.

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

Как принять переход без повторных отгрузок

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

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

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