Яндекс Маркет отключил часть старого API: для крупных селлеров 5 октября стало дедлайном миграции
⚙️ Яндекс Маркет отключил часть старого API: для крупных селлеров 5 октября стало дедлайном миграции
⠀
5 октября закончился переходный период, который Яндекс Маркет дал разработчикам для отказа от части устаревших параметров Partner API.
Для небольших продавцов, работающих вручную через кабинет, почти ничего не изменилось.
Но для крупных селлеров, у которых заказы, остатки, склады и финансовые данные автоматически передаются между Маркетом и внутренними системами, это уже полноценная перестройка инфраструктуры.
⠀
👉 Почему это важно бизнесу, а не только программистам
У крупного продавца кабинет маркетплейса часто используется только для контроля.
Основная работа идет автоматически: заказ поступает во внутреннюю систему, передается на склад, после сборки статус возвращается Маркету, а финансовые данные уходят в учет.
Если интеграция после обновления получает не все данные, продавец может столкнуться с гораздо более неприятной ситуацией, чем просто ошибка на экране.
Например, система загрузит первую часть заказов, но не получит остальные. Формально связь с Маркетом работает, однако часть заказов во внутреннюю систему не попадает.
⠀
👉 Маркет меняет не только способ получения данных
Переход начался еще весной, поэтому неожиданным его назвать нельзя.
Старую схему, где система последовательно запрашивала страницы данных, Маркет заменяет механизмом с токеном следующей выборки.
Одновременно меняются и отдельные поля в данных о заказах, товарах, возвратах и финансах.
То есть недостаточно просто заменить один технический параметр. Нужно проверять, правильно ли после обновления передаются сами заказы, остатки и денежные показатели.
⠀
👉 И это только первый этап
Старый способ получения заказов Маркет тоже постепенно выводит из эксплуатации.
С 18 января 2027 года он может начать работать нестабильно, а 12 апреля 2027 года должен быть отключен окончательно.
Поэтому компаниям, которые сейчас обновили только отдельные параметры, имеет смысл проверить всю интеграцию целиком. Следующая обязательная перестройка уже запланирована.
⠀
👉 Главное
Для крупного продавца API маркетплейса становится такой же критичной инфраструктурой, как складская система или канал передачи заказов на фулфилмент.
Физически товар может лежать на складе и быть готов к отправке. Но если информация о заказе не дошла до внутренней системы, бизнес-процесс все равно ломается.
5 октября показало важный сдвиг: технические изменения маркетплейса все чаще напрямую превращаются в операционный риск продавца.
Чем больше бизнес автоматизирован, тем важнее проверять после обновлений не просто «работает ли API», а совпадает ли количество заказов, возвратов, товаров и финансовых операций в системах продавца и Маркета.
Технически: Маркет прекращает поддержку старых параметров page и pageSize в ряде методов и переводит интеграции на pageToken и limit. Также выводятся из использования отдельные старые поля заказов и магазинов.
Подробнее
Яндекс Маркет поставил дедлайн старому API: с 5 октября интеграции продавцов должны работать по новым правилам
5 октября 2026 года стало важной технической датой для продавцов Яндекс Маркета, которые работают с площадкой не вручную через кабинет, а через API. На эту дату Маркет назначил отключение сразу нескольких устаревших параметров Partner API — от старого механизма пагинации до части полей, которые годами использовались при работе с заказами и данными магазинов.
Для небольшого продавца изменение практически незаметно: если заказы, остатки и отчёты обрабатываются вручную в кабинете, перестройка API его напрямую не касается.
Для крупных селлеров, интеграторов, разработчиков ERP, OMS, WMS, PIM и сервисов управления маркетплейсами ситуация другая. API для них — фактически производственная инфраструктура. Через него могут загружаться сотни и тысячи заказов, синхронизироваться товары, передаваться статусы и попадать данные во внутренние системы учёта.
Поэтому формально небольшое техническое обновление становится инфраструктурной миграцией.
Старую пагинацию начали выводить ещё весной
Переход не был неожиданным.
3 марта 2026 года Яндекс Маркет добавил в метод получения списка магазинов новую токенную пагинацию. Вместо перехода к условной странице № 2 или № 3 интеграция получает специальный идентификатор следующей выборки — nextPageToken — и использует его в следующем запросе.
Уже 4 марта Маркет официально отметил старые параметры page и pageSize как устаревшие сразу для нескольких методов API.
В документации была указана и конечная дата переходного периода — 5 октября 2026 года.
Таким образом, у разработчиков было около семи месяцев на перестройку интеграций.
Вместо page и pageSize — pageToken и limit
Старая схема была классической номерной пагинацией.
Интеграция могла запрашивать:
page=1
pageSize=100
затем:
page=2
pageSize=100
и так далее.
Маркет переводит соответствующие методы на другую схему:
pageToken
limit
В первом запросе токен может отсутствовать. API возвращает страницу данных и nextPageToken. Для получения следующей порции данных интеграция должна отправить полученный токен обратно Маркету.
Такой механизм используется, например, при запросе списка магазинов.
С точки зрения пользователя разница почти отсутствует. С точки зрения разработчика меняется сама логика обхода большого набора данных.
Нельзя просто увеличивать номер страницы. Приложение должно сохранять возвращённый API токен и последовательно использовать его до завершения выгрузки.
Изменение затронуло не один метод
Дата 5 октября была указана как дедлайн старой пагинации как минимум для нескольких важных методов Partner API.
В их числе:
GET v2/campaigns
— получение списка магазинов;
GET v2/campaigns/{campaignId}/orders
— получение заказов магазина;
GET v2/regions/{regionId}/children
— получение дочерних регионов.
То есть речь идёт не об удалении какого-то экзотического служебного параметра.
Один из затронутых методов непосредственно используется для получения заказов — одного из ключевых потоков данных между маркетплейсом и системами продавца.
При этом сам старый GET v2/campaigns/{campaignId}/orders уже находится на следующей стадии вывода из эксплуатации. Маркет пометил его устаревшим и рекомендует переходить на новый метод POST v1/businesses/{businessId}/orders. Согласно действующей документации, с 18 января 2027 года старый метод должен начать работать нестабильно, а 12 апреля 2027 года — быть отключён окончательно.
Получается двухступенчатая миграция: сначала продавцам необходимо отказаться от старой пагинации внутри существующего метода, а затем — и от самого старого метода получения заказов.
Одновременно исчезает часть старой структуры заказа
5 октября — дедлайн не только для page и pageSize.
В ответах методов работы с заказами Маркет также выводит из использования ряд устаревших полей.
Например, shopSku заменяется на offerId.
Поле priceBeforeDiscount, содержавшее стоимость товара до скидки в валюте магазина, также было помечено для отключения 5 октября.
Старое поле details, в котором передавалась информация о невыкупленных или возвращённых товарах, выводится из использования. Для работы с невыкупами и возвратами Маркет предлагает отдельный метод возвратов.
Меняется и структура данных о субсидиях и стоимости заказа. Старое поле subsidy заменяется более новой структурой subsidies, а ряд старых агрегированных денежных полей заказа также помечен как устаревший.
Отдельно из данных магазина выводится clientId — идентификатор плательщика в Яндекс Балансе.
В результате миграция затрагивает не только способ получения следующей страницы данных, но и структуру объектов, которые получает информационная система продавца.
Почему это значительно важнее для крупного селлера
Для магазина с несколькими десятками заказов ручная работа в кабинете ещё возможна.
Для продавца с тысячами SKU, несколькими складами и большим ежедневным потоком заказов кабинет уже становится интерфейсом контроля, а не основной системой управления.
За ним обычно находится собственный технологический контур:
ERP → товарный и финансовый учёт;
OMS → обработка заказов;
WMS → склад;
PIM → карточки товаров;
BI → аналитика;
CRM → работа с клиентами и обращениями;
интеграционный слой → обмен данными с маркетплейсами.
Яндекс Маркет в такой архитектуре является ещё одной внешней информационной системой.
Поэтому изменение API потенциально проходит через всю цепочку.
Если разработчик продолжает рассчитывать, что API примет page и pageSize, перестать работать может механизм последовательной выгрузки данных.
Если внутреннее приложение ожидает shopSku, а в актуальной модели используется offerId, необходимо менять сопоставление идентификаторов.
Если финансовый модуль строится на устаревшем денежном поле, требуется перенести расчёт на актуальную структуру ответа.
А если сторонняя система вообще давно не обновляла коннектор Яндекс Маркета, проблема может обнаружиться уже не на этапе тестирования, а непосредственно в рабочем обмене.
Самый неприятный сценарий — не полный отказ системы
При изменениях API наиболее очевидным риском кажется полная остановка интеграции: запрос вернул ошибку, данные не загрузились, мониторинг её заметил.
Но для бизнеса потенциально опаснее частичная ошибка.
Например, интеграция получила первую страницу заказов, но неправильно запросила следующие.
Система формально работает.
API отвечает.
Ошибки соединения нет.
Однако часть заказов во внутреннюю OMS не попала.
Аналогичная ситуация возможна при изменении структуры ответа: приложение получает объект, но конкретное устаревшее поле больше не содержит ожидаемого значения.
Поэтому техническая миграция требует не только замены названий параметров, но и проверки полноты данных после перехода.
Для крупного продавца контрольным показателем становится не «API отвечает», а «число заказов, товаров, возвратов и финансовых операций во внутренней системе совпадает с данными Маркета».
Почему Маркет переходит на токенную пагинацию
Яндекс Маркет отдельно описывает page как устаревший тип пагинации и рекомендует использовать pageToken, если метод поддерживает обе схемы.
Экономический смысл такого изменения находится уже на стороне инфраструктуры платформы.
Номерная пагинация удобна для пользователя, но при больших и быстро меняющихся массивах данных может создавать более сложную работу на стороне сервиса. Между запросом первой и десятой страницы набор данных способен измениться: появляются новые записи, меняются статусы, часть объектов перемещается относительно границ страниц.
Токен позволяет платформе самой определять способ продолжения выборки и не привязывать внешний клиент к внутренней структуре хранения данных.
Это стандартная логика развития крупного API: чем больше объём операций, тем меньше внешней системе дают управлять внутренней механикой выборки.
Для Яндекс Маркета такой переход косвенно показывает и зрелость самой платформы. API перестаёт быть дополнительным способом автоматизировать кабинет и становится самостоятельным инфраструктурным слоем для профессиональных продавцов и сервисов.
Миграция API у Маркета на этом не заканчивается
5 октября не выглядит конечной точкой перестройки Partner API.
Маркет последовательно выводит из эксплуатации старые методы и параметры.
Самый показательный следующий этап касается заказов.
Старые методы:
GET v2/campaigns/{campaignId}/orders
и
GET v2/campaigns/{campaignId}/orders/{orderId}
уже признаны устаревшими.
Для получения заказов Маркет переводит интеграции на:
POST v1/businesses/{businessId}/orders.
По действующей документации, старые методы с 18 января 2027 года могут работать нестабильно, а 12 апреля 2027 года должны быть отключены.
То есть компания постепенно меняет не только отдельные параметры, но и архитектуру API работы с заказами.
Для разработчиков это важный сигнал: исправить только page на pageToken недостаточно. Интеграцию имеет смысл проверять целиком на использование deprecated-методов и полей, иначе следующая обязательная миграция потребуется уже через несколько месяцев.
API становится частью операционного риска продавца
У маркетплейсов есть хорошо заметная физическая инфраструктура: склады, сортировочные центры, ПВЗ, курьеры.
Но у крупного e-commerce-бизнеса существует ещё один, менее заметный слой — цифровая логистика данных.
Заказ должен не только физически появиться на складе. Сначала информация о нём должна попасть из маркетплейса в OMS, затем в WMS, после сборки статус должен вернуться обратно, а финансовые данные — попасть в учётную систему.
Если эта цепочка нарушается, физически исправный склад сам по себе не спасает операцию.
Поэтому для крупного продавца API маркетплейса постепенно становится такой же критичной инфраструктурой, как WMS, платёжный шлюз или канал передачи заказов на фулфилмент.
Изменение, которое для пользователя кабинета выглядит как техническая строка в документации, для крупного селлера означает полноценный релиз интеграционной системы: разработку, тестирование, проверку сопоставления данных, выкладку и мониторинг после миграции.
Что изменилось именно 5 октября
Главное здесь — не появление новой функции API.
Новые механизмы существовали заранее.
Токенная пагинация появилась ещё в марте, а старые параметры одновременно получили статус устаревших.
5 октября 2026 года закончился объявленный Яндекс Маркетом переходный период. Именно эту дату документация площадки указывала как дату отключения page, pageSize и ряда других legacy-параметров.
Поэтому для интеграций, которые всё ещё зависели от старой структуры API, 5 октября стало фактическим дедлайном миграции.
Для рынка это характерное изменение зрелого маркетплейса: площадки постепенно стандартизируют не только тарифы, логистику и требования к карточкам, но и технологический способ подключения бизнеса к своей инфраструктуре.
И чем крупнее продавец, тем меньше такие изменения можно считать исключительно задачей IT-отдела. Ошибка в API способна очень быстро превратиться в операционную ошибку — пропущенный заказ, неправильный остаток, некорректный финансовый показатель или расхождение между маркетплейсом и учётной системой.
Источники
- Яндекс Маркет — документация Partner API, получение списка магазинов. Параметры page и pageSize, переход на pageToken и limit, дата отключения 5 октября 2026 года.
https://yandex.ru/dev/market/partner-api/doc/ru/reference/campaigns/getCampaigns - Яндекс Маркет — документация Partner API, получение заказов магазина. Старая и новая пагинация, а также дальнейший вывод метода из эксплуатации.
https://yandex.ru/dev/market/partner-api/doc/ru/reference/orders/getOrders - Яндекс Маркет — документация Partner API, получение дочерних регионов. Дата отключения параметров page и pageSize.
https://yandex.ru/dev/market/partner-api/doc/ru/reference/regions/searchRegionChildren - Яндекс Маркет — документация Partner API, изменение статуса заказа. Устаревшие поля details, priceBeforeDiscount, shopSku, subsidy и другие параметры с дедлайном 5 октября 2026 года.
https://yandex.ru/dev/market/partner-api/doc/ru/reference/orders/updateOrderStatus - Яндекс Маркет — журнал главных обновлений Partner API. Изменения 3–4 марта 2026 года: добавление токенной пагинации и объявление page и pageSize устаревшими.
https://yandex.ru/dev/market/partner-api/doc/ru/changelog/main - Яндекс Маркет — описание механизмов пагинации Partner API и использования pageToken.
https://yandex.ru/dev/market/partner-api/doc/ru/concepts/pagination - Яндекс Маркет — список устаревших методов и параметров Partner API.
https://yandex.ru/dev/market/partner-api/doc/ru/changelog/deprecated
