Привет!

Команда WB API планирует в перспективе отказаться от методов /api/v1/supplier/orders и /api/v1/supplier/sales.

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

Пожалуйста, поделитесь:

• для каких бизнес-задач вы применяете эти методы;
• какие данные из ответов используются в ваших системах;
• какие трудности или ограничения вы сейчас испытываете.

Отказ от указанных методов предполагает реализацию альтернативы, которую мы предлагаем открыто обсудить и спроектировать совместно. Команда Продукта WB API совместно с командой Поддержки продавцов будет следить за обсуждением и готова отвечать на вопросы в теме.

Добрый день! У нас на этих отчетах завязано очень много аналитических процессов: от ежедневной статистики заказов по товарам до составления заказов поставщикам и планирования поставок на склады ВБ. Для нас очень важны данные о составе заказа (именно ШК товара/размера), с какого склада был сделан заказ, в какой регион, по какой цене и СПП, текущий статус заказа. Так же иногда эти данные используем для уточнения данных в ежедневных/еженедельных финансовых отчетах по srid.

Основная проблема этих методов - неполные данные в выдаче. Если сравнивать с отчетами в ЛК, то по API ежедневно приходит примерно на 10% меньше заказов, чем в ЛК в разделе Аналитика/Отчеты/Продажи. Расхождения тянутся уже больше полугода, но обращения в тех.поддержку не помогают.

Добрый день.

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

Основные проблемы:

1. Не совпадает количество заказов с данными из Личного Кабинета.

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

Приведу пример:

• делаем выгрузку заказов 17.12.2025 за период 01.12.2025 - 16.12.2025. Получаем, что за 01.12.2025 было 10 заказов.
• делаем выгрузку заказов 31.12.2025 за период 01.12.2025 - 30.12.2025. Мы видимо, что за 01.12.2025 было 15 заказов, а не 10, как в прошлую итерацию. Откуда взялось ещё 5 заказов - вопрос. Тех. поддержка не смогла нам ответить.

3. Было бы здорово предусмотреть в методе период, за который нужно получить заказы (по типу dateFrom и dateTo в других отчетах). Получение заказов за определенный период в текущем виде не очень интуитивна.

Заказы - метод, в котором есть широкий функционал, который удобно использовать, и который не вполне есть в других методах, воронка, продажи по регионам итп. Если заказ даже обрабатывается ВБ, всё равно бывает информативно, анализировать статусы, по конкретным заказам. Также, в нынешнем виде он позволяет более оперативно тянуть данные по заказам, чем воронка, где нужно группировать по дням, с паузами по 20 секунд, чтобы получить информацию в разрезе дней. А если например нужна информация в разрезе часов, то это вообще только в заказах можно получить. Единственная проблема с заказами, как уже все написали, кривизна данных. Что честно говоря совершенно непонятно отчего, учитывая что ваши синие и желтые друзья прекрасно с этим справляются.

Добрый день!

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

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

Нужен srid, характеристики товара - баркод, артикул, размер, суммы заказа и продажи (до спп и фактические), даты заказа и продажи, склад отгрузки и куда едет товар.

Не используем для этих целей воронку, потому что тут именно первичка - до srid заказа.

Для поставок это используется, потому что есть понимание в какой регион, с какого склада какая текущая скорость заказов и продаж. Исходя из скорости заказов, продаж и остатков понимается сколько нужно догружать.

Мы показываем в итоге список заказов селлеру, куда сначала попадает информация из orders, там есть цена, дата, айди, товар итп. Далее когда заказ выкупают - мы обогащаем в списке заказов по srid данные о фактической цене покупки (видим комиссию маркетплейса), обогащаем информацию про регион, дату продажи. Когда проходит недельный отчет - оттуда в список закаказов заменяем данные о фактической цене, комиссии, добавляем сумму логистики в одну или обе стороны в зависимости от того был ли отказ (впоследствии если возврат, то сторнируем сумму продажи, комиссии и добавляем логистику возврата).

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

Ну и еще раз напишу, что нам важно до srid заказа, до первички - по ним мы собираем данные из недельных отчетов и оперативных данных (orders и sales).

Скажите, пожалуйста, что вы имеете в виду под ежедневной статистикой заказов и почему для этого не могут подойти, например, методы воронки продаж? Каких данных в методах воронки продаж не хватает для ежедневной статистики заказов по товарам? Также подскажите, на основании каких данных вы составляете заказы поставщикам и планируете поставки? Не хватит ли для этого понимания остатка на складах? Если нет, то почему?

Дам свои комментарии к вопросам, заданным коллегам.

Нужна именно первичная информация, вашим аналитическим данным мы не доверяем, когда вы сами группируете и показываете уже готовые цифры, то мы не можем их никак проверить, и не можем дать ответы, почему это не совпадает с ЛК или другими АПИ ендпоинтами.

Поэтому лучше дайте нам первичку, а мы по ней будем уже сами делать аналитику, в которой мы уверены.

Поставки планируются исходя из скорости заказов и продаж, поэтому это важно.

Для чего вы используете данные о составе заказа, например, информация о том, в какой регион был сделан заказ? Если вы хотите понимать, на склады каких регионов вам выгоднее делать поставки, это можно определить исходя из количества продаж по регионам (ссылка на документацию https://dev.wildberries.ru/openapi/reports#tag/Prodazhi-po-regionam).

Тоже доверяем первичке, мы сами хотим просуммировать, посчитать количество и быть в нем уверены, нежели полагаться на ваши алгоритмы. Может не совпадать методика, могут быть ошибки.

Информацию о цене и СПП можно получать из детализации к ежедневному/еженедельному отчёту по продажам. Почему вам не подходит эта информация из детализаций к отчётам по продажам, если вы, по вашим словам, всё равно сравниваете данные из этих двух методов с финансовыми отчётами?

По заказам данные появляются (или ранее появлялись) только после первых начислений по нему - логистики. А она происходит, когда человек пришел на ПВЗ. Поэтому чтобы показать сумму заказов нужна цена заказа как можно ближе к дате и времени заказа клиентом.

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

Селлеры считают % выкупа, считают как отработал блоггер - сколько было заказов в этот день, они не относятся к схеме FBW как "поставил и забыл". Они хотят видеть как работает реклама, как работает воронка, если % выкупа начал снижаться (отказы), то как можно быстрее предпринимать какие-то меры.

Скажите, пожалуйста, что вы имеете в виду под регулярным мониторингом заказов? Зачем вам необходимо мониторить FBW-заказы, если продавец ими не занимается? Что вы делаете с этими данными? Почему планируете поставки исходя из количества заказов, а не исходя из количества остатков на складах?

Тоже отвечу на вопросы, заданные коллегам, со своей колокольни:

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

Расскажите, пожалуйста, подробнее про аналитику рекламы. Какую информацию из методов /orders и /sales вы используете для аналитики рекламы, и как именно? Каких данных не хватает в методах для работы с рекламой, чтобы вы смогли делать такую аналитику?

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

Кстати, если в альтернативном инструменте списка заказов вы сделаете еще и источник заказа, из рекламы он или из органики, с какой поисковой фразы, итп. То, что вы потом испольщуете в аналитических отчетах - если добавите в первичку по заказам - это будет очень здорово.

Вообще не вижу смысла в этих ручках. Всё нужное есть в воронке и фин.отчёте (reportDetailByPeriod), тем более там теперь ежедневные можно получать.

Здравствуйте! Из отчета о заказах мы получаем ежедневную статистику заказов по товарам, информацию о том, с какого склада был сделан заказ, в какой регион, по какой цене. Это важно для своевременной поставки товаров на склады. Отчет об остатках товаров на складах мы тоже используем. В финансовых отчетах необходимые данные появляются позже, после получения заказа покупателем.

Работаем по модели FBS Используем эти отчеты чтобы получать цену продавца в момент заказа, чтобы выстраивать прогнозную аналитику В ручке получения всех сборочных заданий данной информации нет, она присутствует только в списке новых сборочных - этого не хватает для товаров в пути, потому что какие-то товары успевают перевести в сборку до того, как прошло обновление и соответственно информация по товарам меняется

Так же используем оба отчета для отсмотра каждого заказа сделанного с остатков на складах FBW в пути, чтобы отслеживать ежедневную тенденцию по каждому артикулу - особенно это влияет в категориях, где процент выкупа может быть меньше 50%, когда большинство заказов с FBS уезжают на склад ВБ

Критически не хватает информации о заказах, сделанных из Белоруссии, Казахстана и т.д. - только спустя пару недель из еженедельных/ежедневных можно что-то достать, что очень странно, потому что по остальным то заказам информация приходит сразу

Методы используются для сбора оперативной информации, которую можно отследить до определённо заказа.

Агрегированные информации в воронке и Продажи по регионам не достаточно, потому что не понятно с какого склада ушло, с каким кол-вом, и как проверить корректность фин.отчёта и найти "потеряшки".

Данные по СПП мы используем на основе заказов, так как ждать выкупа можно долго (~5 дней доставка + 14 д. забор клиентом). Также по складу заказа, не все склады могут принять все товары и нужно понимать альтернативы.

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

В текущем методе была бы полезна уже понятная информация по затратам (комиссия, эквайринг).

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

Мы отслеживаем все заказы и их статусы. Метод критически важен Как дополнительный способ контроля продаж в еженедельном отчете (по каждому заказу идет сверка с отчетом)

1. За какой срок доезжает заказ до клиентов в какие регионы и с какого конкретно склада он так долго ехал. Бывают заказы в Хабаровск, например, которые по 20 дней в дороге

2. Отследить фин отчеты, т.к. есть погрешность до 1%, которая может тянуться по полгода и чтобы сразу устранить этот момент есть возможность написать в поддержку

3. Увидеть отказы откуда ездят и в целом заказы, т.к. бывает конкуренты промышляют нехорошими делами и аномальные заказы могут прилететь, что очень хорошо видно в выгрузке по заказам

4. Защита от недобросовестных блогеров, когда им даешь товар на интеграцию, возмещая за него деньги, а они потом сдают его обратно и портят % выкупа

5. Отследить товары-потеряшки, чтобы оперативно решить это с поддержкой, которые по полгода в пути

6. Ну и базово посчитать количество заказов и выкупов, которые некорректные, но хотя бы есть четкая картинка что этот заказ реально был, а не просто цифры итоговые

А главное это все решается под капотом одного метода, а если сейчас под каждую нужду будет отдельный метод, то это очень большая вычислительная нагрузка

Аналогично коллегам используем отчеты для детальной аналитики, сколько заказов было в 1 руки (первая часть srid одинаковая), сколько заказов отмени (отказались в ПВЗ, сколько возвраты и т.д.) Временные промежутки интерсивности заказов, региональное распределение. Так как данные в отчетах детальные то доверие к ним существенно больше, чем к обезличенной воронке продаж, давнные в которой не бьются ни с заказами, ни с продажами, ни с реализацией, в части заказов и выкупов. К ним доверия нет. С полявлением ежедневных отчетов данные по продажам может и не так важны, а отчет по всем заказам необходим. Иначе прозрачности работы площадки никакой нет.

Добрый день.

Мы ежедневно пользуемся данными методами API. Методом order получаем информацию о заказах, а методом sales информацию о доставке заказа, на основании сравнения этих данных по srid формируем закрывающие документы. Нам важно иметь индивидуальный РТУ и возврат под каждый заказ в 1С, их несколько тысяч в неделю, заносить эти данные вручную невозможно. Все полученные данные используются для сверки еженедельных отчетов, это сильно ускоряет работу. Мы регулярно выявляем разницу в данных полученных по API в сравнении с ЛК. Также этот метод помогает нам в проведении потоварных сверок и отслеживании выплат компенсаций по нашим обращениям. Раз в неделю мы проводим учет ШК, эти данные удобно грузить через API.

Данный метод очень важен для нас. Просим улучшить соответствие данных с ЛК.

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

В методе нет разделения FBO и FBS, а обещанный номер поставки обычно 0, приходится позже подтягивать данные из отчета по реализации.

Добрый день!

Мы активно используем метод /api/v1/supplier/orders для оперативного мониторинга (обновление каждые 30 минут). Он критически важен для анализа заказов, цен, СПП и региональных приоритетов. Даже с учетом отдельных временных задержек (например, incomeId появляется через 4-5 часов) мы смогли интегрировать эти данные в нашу систему.

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

Очень просим не сокращать и не отключать этот метод. Лучше доработайте его, ведь это важная первичная информация от Вас.

Мы и наверное многие коллеги вложили значительные ресурсы в адаптацию, интеграцию и построение аналитики на основе этого API. Любые изменения сейчас — это серьезные дополнительные издержки для бизнеса и отвлечение от ключевой задачи — продаж.

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

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

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