Всем привет. Я уже примерно 3 года занимаюсь ведением рекламы на маркетплейсах, в частности ВБ, и поскольку люблю все автоматизировать - разработкой и поддержкой инструмента для управления рекламными кампаниями и аналитикой через публичный API Wildberries.
И в целом я уже привык к тому, что иногда новые версии методов абсолютно не соответствуют старым, даже там, где можно было сделать обновленную версию с минимальными изменениями, чтобы разработчик просто поменял URL ендпоинта. Привык что приходится иногда делать работу ради работы по сути, потому что кто-то не продумал заранее проблемные нюансы.
Но в последнее время в АПИ произошло такое количество изменений, и они настолько напрягают своими неочевидными ошибками, что уже "накипело", и хочется это сформулировать в виде какого-то структурированного текста с примерами, вдруг кто-то из команды обратит на это внимание.
Постараюсь описывать проблемы WB API не с позиции «пользователя, которому не понравилось», а с точки зрения интегратора, который отвечает за стабильную работу рекламы для нескольких клиентов с миллионными оборотами. Я сознательно опускаю детали реализации и не привожу конкретные ID кампаний и запросы, но описываю поведение, воспроизводимое на сотнях кампаний нескольких клиентов.
Обратная совместимость и бизнес-логика
Я понимаю что некоторые методы действительно сложно написать, не меняя структуру вопроса-ответа. Но в некоторых моментах складывается ощущение, что разработчики АПИ не просто не думали об удобстве использования для интеграторов, а специально накинули им работы. Чтобы не быть голословным, давайте свежий пример.
Были у нас поисковые кампании (они же Аукцион) типа 9, и автоматические кампании (сокращаю до АРК) типа 8. Если очень упростить, то Аукцион показывается в поиске по запросам и стоит дороже, АРК показывается везде где только можно, но стоит дешевле. Все что не Поиск - называется Рекомендательные полки: в карточках товара, может кинуть на главную страницу, в корзине и тд, ВБ тестирует новые места показов иногда.
В обоих типах кампаний можно минусовать (исключать, останавливать показы) по поисковым запросам, которые вас не устраивают. Есть методы получения списков активных и исключенных запросов кампаний, есть методы исключения. Конечно были свои нюансы, например отдельно показами в рекомендательных полках мы не могли управлять. Но, как это бывает в жизни, спустя время мы понимаем, что было все не так уж плохо.
Что есть сейчас (вам не обязательно запоминать все). Появился еще тип ставки - единая или ручная. АРК представлены и в типе 8 и типе 9. Называется Единая ставка. В типе 8 у старых кампаний некоторых почему то технически тип ставки не проставился (будет важно потом). В типе 9 теперь может быть или Единая или Ручная ставка. В Ручной ставке могут быть показы или в поиске, или в рекполках, или комбинированные. Методы статистики и управления разбили на методы для ручной ставки и для единой ставки. И чё - спросите вы.
А например то, что для типа 8 у которых тип ставки не проставился почему то у них в системе - методы для единой ставки не работают. Никакой внятной ошибки об этом не выдается. Если вы отправили в запросе 100 кампаний - ляжет весь запрос без указания ошибочных кампаний. Велком ту ручная отправка 30-40 запросов по одной кампании, чтобы найти в какой ошибка, и сломать голову, в чем проблема.
То, что теперь мне нужно все места в системе, где раньше я делал выборки по типу 8 или 9 (у них тоже были разные методы для некоторых действий) - переписывать на "все типа 8 без ошибок типа ставки ИЛИ тип 9 с единой ставкой" и "тип 9 только с ручной ставкой". Ах кстати, в типе 9 же еще может быть оплата за показы и за клики, и некоторые методы статистики будут тоже падать с ошибкой из-за того что в 100 кампаниях встретится одна с оплатой за клики.
В итоге куча времени уходит на то, чтобы разобраться во всех этих нюансах, потому что не все они указаны в документации.
А давайте представим, как был бы прекрасен мир, если бы тип 8 не стали запихивать в тип 9, а оставили как он и был. Допустим в типе 9 сделали возможность управления местами показа, окей. Ну и кликовые кампании вынесли в отдельный тип, условно 10.
Для внешних интеграторов это означало бы минимальное количество изменений в своих системах.
А давайте еще один пример. Помните запросы можно было минусовать в авто и поисковых кампаниях? Вот сейчас в авто кампании все работает как работало, а в поисковых кампаниях ввели новое (старое) понятие - нормализованные запросы, они же кластеры запросов, они же пресеты.
Если кратко, то поиск у вб строится не отдельно по поисковым запросам, а по группам запросов - пресетам или кластерам. Например "одежда женская" и "одежда для женщин" будут в одном кластере. А нормализованный запрос - это как бы главный запрос кластера. Так работало всегда на моей памяти, но минусовать мы могли хоть все запросы из одного кластера.
А теперь ВБ сказали - минусовать можно только нормализованные запросы, у которых было более 100 показов. Оставим в стороне вопрос эффективности рекламы, рассмотрим как они это технически реализовали.
Раньше мы просто отправляли массив минус-фраз кампании размером не более 1000 фраз. В моменте этот метод продолжил работать корректно, и другой метод, возвращающий минус-фразы, их корректно возвращал.
НО ввели новые методы, при этом старые продолжали работать и были активны в документации, нигде не было написано что они не работают.
А вот показы по отминусованным старыми методами с какого то момента запросам продолжались, потому что они были не отминусованы новым методом.
Само собой после снижения эффективности рекламы и дебага это выяснилось, но разве так это должно быть организовано?
Ок, думаю, значит надо быстренько все переводить на новые методы минусации. Тут тоже свои приколы.
Помните, что новый метод дает отминусовать запросы у которых было более 100 показов? Так то оно так, но только 100 показов - это очень эфемерное определение, как выяснилось.
У меня вся стата по всем запросам хранится в базе данных. Думаю, ну все же просто - было по запросу более 100 показов суммарно, значит можем минусовать. Нет. ВБ решили считать это как-то под капотом по новому. В итоге запросы которые по статистике из их же официальной документации ранее имели несколько ТЫСЯЧ показов - отминусовать нельзя.
Ответ - берите запросы из нового метода статистики по запросам, который показывает запросы у которых по каким-то новым расчетам ВБ было более 100 показов, и минусуйте по ним. Старый метод мол че-то другое вам показывает.
Да нет проблем, только эти методы на несколько дней начали показывать все запросы, даже которые нельзя минусовать - и соответственно у меня в системе данные что запрос можно минусовать, а он не минусуется...
И знаете в чем еще прикол? Из отправленной условно 1000 минус-фраз в ошибке АПИ вернет вам только ОДНУ ошибочную. То есть не "вот у тебя 300 запросов не минусуются, убери и пришли остальные 700 нормальных", а "вот у тебя из 1000 один не минусуется - ты его убери и еще раз попробуй, не знаю сколько у тебя там еще не минусуется, да ты и сам не знаешь, дерзай". И в итоге стабильно рабочего метода обнаружения и минусации всех запросов, которые можно минусовать - просто нет.
И чуете чем пахнет? Методы получения минус фраз кампании - новые с новой структурой. Методы минусации - новые с новой структурой и непонятным алгоритмом работы с ними. Методы статистики - новые. Поменялось буквально все в коде, с одним единственным изменением по сути - нельзя отминусовать запрос, если по нему было менее 100 показов.
А как был бы прекрасен мир (если бы вообще не вводили это ущербное правило) если бы оставили все те же самые методы с новой версией в URL, но например в метод минусации добавили возврат запросов, которые не может отминусовать ВБ по новому правилу. Отправил 1000 - 700 отминусовали, 300 нет, будь в курсе. И ВСЁ, это потребовало бы от интеграторов не несколько дней танцев с бубном, а 15 минут, из которых 10 ушло бы на кофе.
Магические ошибки
В принципе я описал это выше, но это отдельная боль, которую очень хотелось бы перестать ощущать. Какие то неверные данные в кампаниях мешают корректной работе метода, но ты вместо "кампании 123, 456, 789 у тебя cpc, а должны быть cpm, не тупи", ты получаешь "что то не так с кампаниями" и методом научного тыка находишь проблемные кампании, а потом пробуешь понять, какие поля в них отличаются от кампаний, где все работает. Очень блин информативно, спасибо.
Отсутствие важных данных в АПИ
Такая проблема есть в любом апи наверное, и к ней бы было сильно меньше вопросов, если бы апи просто не развивался. Но почему то у команды разрабов есть время на введение кучи изменений, часть из которых, как описано выше, можно было вообще не делать, и все бы выиграли от этого, а вот на то чтобы добавить пару методов или вообще полей в существующие методы - у них почему-то времени (желания) не хватило.
Из базовых примеров - уже несколько месяцев назад ввели показатель Показы в воронку продаж в личном кабинете. То есть вы можете увидеть сколько посетителей видело ваш товар в поиске, сколько перешло, сколько добавило в корзину и тд. Конкретно показатель Показы очень важен тем, что с ним можно будет более-менее понимать CTR карточки товара, и быстрее прорабатывать товары, на которые кликают хуже. При чем уже после его ввода выкатили новую версию АПИ воронки продаж, но показателя показы там нет ))
Есть на ВБ такая штука, как аналитика внешнего трафика - возможность ставить внешние ссылки на свои товары и отслеживать статистику по ним по UTM меткам. Существует она в личном кабинете несколько лет. Согласитесь, для автоматизации отчетности и оптимизации рекламы было бы логично иметь апи ендпоинт для получения этой статистики. Но его нет. Точка.
Еще пару лет просим добавить разделение статистики кампаний по местам показа. Новые методы статистики появляются, данные - нет. Ну это база, беспокоит не так сильно потому что отчасти решается разделением кампаний по типу. Но опять же, в единой кампании так сделать уже не получится.
Отрицание проблем селлеров
Это конечно не совсем про АПИ, но проблема крайне важна, поэтому оставлю ее здесь. Как писал выше, запретили минусацию кластеров, где было менее 100 показов.
И ладно бы сказали "нам дорого обслуживать такой объем данных" или "у нас план на 10% увеличить выручку с рекламы, идей больше нет", ну или какую-то другую более уверенно звучащую причину.
НО они говорят "ну по таким запросам могут быть заказы тоже", "чем больше трафика тем лучше", "100 показов мало для принятия решения". А если у меня товар условно акриловые краски показывается по запросам типа баночки для краски, ткани для росписи и так далее?
То есть откровенно нецелевые запросы за которые я не готов платить например 30 копеек за каждый показ, а минимальные ставки сейчас примерно такие в поиске, 300+ рублей за 1000 показов.
А если у меня однотипные товары добавляются в продвижение, я уже с ними 2 года работаю, и знаю заранее, какие запросы для товара точно не будут работать?
Есть товары у которых в кампанию накидывает по 2-3 тысячи запросов. Из них может быть 70-80% нерелевантных, а иногда и больше. И если раньше их можно было исключать заранее, или по крайней мере на этапе когда они еще не успели скрутить много показов, то теперь за них придется платить пока они не наберут эти пресловутые 100 показов. Каким бы ни был неподходящим к товару запрос - плати. Я понимаю что налоги растут, но это уже как налог на воздух.
А приводит это только к тому, что сейчас приходится снижать ставки в кампаниях (или значительно медленнее их повышать), потому что эффективность расходов на рекламу значительно снизилась. В итоге сам ВБ зарабатывает меньше, и скорее всего решать это будет повышением минимальных ставок.
Ну а селлерам останется только убирать из продвижения товары по мере того, как продвигать их становится экономически нецелесообразно. На мой взгляд было бы значительно эффективнее давать селлерам гибкие инструменты точечного управления рекламой, чтобы все были в выигрыше.
Насильно впихивать показы по запросам "мыть", "средство от", "для чистки", "подтеки" и так далее - это все равно что на рынке в ящик клубники подсыпать вниз гнилые ягоды. Продать-то может и продадите, но осадочек как миниум у покупателя останется. Конечно селлер привязан к ВБ сильнее, чем покупатель к рыночному торговцу, но все равно последнее время лояльность селлеров к этому маркетплейсу сильно снижается.
Вывод
Я если 2 года назад отдавал полностью предпочтение ВБ в битве за удобство и эффективность настройки рекламы по сравнению с другими маркетплейсами (конечно при наличии софта и интеграций, но тем не менее), то после всех этих изменений уже так сложно сказать.
Проблема не в сложности рекламной системы. С ней нет проблем разобраться и обычному селлеру, и тем более интегратору или разработчику. Проблема в том, что ошибки становятся неуловимыми, старая логика работы рушится без обратной совместимости там, где этого можно было легко избежать. И решение этих проблем перекладывается по сути на селлеров и интеграторов.
Если добавить ложку меда - конечно добавили управление ставкой по кластерам и это очень круто. И управление ставками по местам показа. Но стоит ли овчинка выделки - вопрос. Я надеюсь что рано или поздно ВБ эти проблемы решит с учетом интересов селлеров, потому что все участники рынка в этом заинтересованы.
P.S. Еще одну проблему вспомнил на следующий день - названия одних и тех же полей в разных методах апи меняют практически всегда при изменении версии. Были у тебя addToCard, могут в следующей версии стать cardCount, а потом cards ну и так далее. Между разными типами статистики это тоже может быть то согласовано, то нет.
Комментарии (18)
LIDS
13.12.2025 17:15Я так скажу. За последние дни они еще выкатили кучу обновлений, и я просто устал вычитывать эти изменения.
При этом Вы говорите про типы акции 8 и 9, а у меня еще и 6 всплыли. и я просто устал читать документацию, в которой абсолютно ничего не написано про типы РК.
Яндекс молчу.
Худшей интеграции я не видел еще. но они меняются.
DigitalSfera Автор
13.12.2025 17:15Утверждать не буду, но вроде как 6-ой тип (это раньше тоже поиск был) перевели внутри их системы в тип 9 уже давно. Может это завершенные давно кампании? Напрягает скорее не поток обновлений, обновления то это хорошо, а то, что надо в каждом разбираться, не сломается ли завтра из-за него вся система, потому что очередное гениальное решение обратной совместимостью не пахнет вообще.
KonstantinVladimirtsev
13.12.2025 17:15Господи,как же я завидую человеку,который еще не работал с api Озона...
Буквально каждый раз, когда я сажусь сделать что-то с любым из методов, заканчивается все истерикой и вызовом полиции соседями, из-за гневных оров на всю многоэтажку
DigitalSfera Автор
13.12.2025 17:15А кто сказал, что я не работал?)) Озон тоже использую, просто не так активно, как вбшный апи, поэтому наверное не могу такой же объем проблем по ним выдать. Ну у них тоже свои приколы, согласен. Но последние пару лет они стараются если какие то методы и менять, то мягко, чтобы по минимуму пришлось переделывать. По крайней мере насколько я помню, потому что по озону ну было за это время авральных ночей с переписыванием всего. Меня больше всего напрягает асинхронное создание отчетов, даже самых маленьких, но в целом с этим можно жить и их тоже можно понять, почему так сделали.
KonstantinVladimirtsev
13.12.2025 17:15Немного боли и нытья:
У нас есть 4 разных идентификатора товара. И да, в разных ручках мы будем просить разные идентификаторы
Хочешь получить контент по товару? Будь добр сходить на три эндпоинта, чтобы получить таки ссылки на главное фото
Хочешь по API узнать сколько в поставке на FBO было заявлено, а сколько по факту принято? А не дофига хочешь?
Хочешь по API создавать поставки? Пока разрабатываешь решение делаешь тестовые запросы? 429. Создал черновик заявки на поставку и в течении суток отправил заявку с такими же данными(те же sku с таким же количеством)? 429. Прошел мимо компа, на котором в теории можно было бы написать код, который отправлял бы запросы к API Ozon? 429. Продал все имущество, разорвал контакты со всеми друзьями и близкими. Уехал на необитаемый остров. Поздно вечером видишь бутылку, которую прибило к берегу. Поднимаешь и видишь там записку. Достаешь. 429
У нас практически все отчеты отдаются в json. Хочешь статистику по рекламе? Сходи на 4 ручки и дождись генерации отчета. За раз можно создавать отчет на статистку не более, чем по 10 компаниям. В одно время может создаваться только 1 отчет для одного аккаунта. Создаваться отчет может и час и два. Ах да, мы же думаем о разработчиках, поэтому это один из 3-х методов, которые отдают данные в CSV. Хочешь в нормальном json? Ну так просто добавь в ендпоинт /json. Хочешь внятную документацию о том, что возвращается в json? Ну сделай запрос и посмотри, че сервер вернет. Маленький что-ли? Во всех отчетах мы отдаем дробные числа с точкой? Ну так в этом мы будем отдавать их с запятой
У товара есть предмет(вешалка, футболка и т.д.)? Ну так мы во всех отчетах будем отдавать не значение предмета, а его id в нашей системе. Выгрузки отдельно отчет по предметам и сопоставь
У тебя есть поставки FBS? Один заказ может содержать несколько товаров? Ну так мы в отчете по транзакциям будем отдавать только часть списания. Хочешь узнать сколько стоила логистика на заказ? Ну так у тебя есть 3 цифры - стоимость заказа, размер комиссии, стоимость последней мили, вычти все это и получишь стоимость доставки. А, точно, у нас же есть 20 разных меток на транзакцию и для каждой из этих меток, мы одни и те же цифры отдаем в разных полях. А, ну и эквайринг мы списываем, только вот идентификатор заказа мы меняем, чтобы тебе сложнее было сопоставить эту транзакцию с отчетом по заказам. Ты хочешь считать размер налога? Ну на глаз прикинь, мы тебе нигде не скажем, сколько заплатил клиент, чтобы от этой суммы считать налог.
У нас есть отчет по реализации, но там мы отдаем только парочку значений, на основании которых ты не сможешь посчитать свою маржинальность. А так как в отчете по транзакциям мы тоже не все транзакции отдаем, то удаче тебе, узнать прибыльный твой магазин или нет
У нас есть отчет по Воронке! Написали ли мы к ней документацию? Ну как-бы да. Правда тело ответа не постоянно и так как ответ зависит от того, есть ли у тебя подписка за 25к, то мы тебе не скажем, что будет в ответе. Ты можешь управлять этим телом и передавать в теле запроса, какие параметры нужно вернуть. Только вот те названия параметров которые ты в теле запроса передаешь, не совпадают с теми, что мы вернем в ответе
И это только то, что я смогу на вскидки вспомнить, пока писал этот комментарий. По факту, там практически в каждом методе да есть какая-нибудь тупость. Типо того, что в ответе метода в котором есть товары, мы не получаем sku а только артикул продавца или для того, чтобы получить какой-нибудь простой отчет. тебе нужно выгрузить еще 4 других. Все это, конечно не конец света, это не делает API нежизнеспособным, но все это увеличивает время на разработку порой в три, а то и в четыре раза, просто потому что если разработчик API Озона придумывает что-то адекватное и логичное, его сразу же бьют палкой по башке
DigitalSfera Автор
13.12.2025 17:15Ахахахах, годно) Я забыл про ID товаров, да, это боль. У меня постоянно расчет прибыли по ним ломается, потому что вроде как product_id должен быть уникален, но как бы ввели то ли сборки то ли что (когда сразу много товаров уходит одним заказом, не помню точно) - продукт айди там дублируется, а вот ску айди разный)) Да, все, я забыл об этих приколах пока бомбил с вб, извиняйте. Ну рекламные отчеты асинхронные к этому я уже привык, json там достаточно понятный. Отчет кстати не может готовится 2-3 часа, после часа подготовки он упадет с ошибкой и можно будет пересоздать. Ограничение на 10 кампаний тоже достаточно тупое. Ну крч да, боли тоже хватает ))((
KonstantinVladimirtsev
13.12.2025 17:15Просто ощущение, что они скоро начнут донаты просить на сервера, чтобы увеличить лимиты на запросы, потому что им слишком дорого их обслуживать.
И разработчики словно изначально собирали внутреннюю архитектуру дилетанты, а после пришли профессионалы и пытаются на старой, кривой и косой архитектуре строить api исходя из канонов разработки с изоляциями, отдельными сущностями и т.д. вообще не думая о том, что этим будет кто-то пользоваться. И тем более, этим будет пользоваться кто-то, кто не хочет тратить целый день, на то чтобы собрать метод для получения отчета по остаткам
KonstantinVladimirtsev
13.12.2025 17:15У WB безусловно хватает и своих приколов. Взять тот же метод для получения контента, где вместо нормально пагинации через limit и offset, нам нужно проверять total и передавать cursor. Или тот же ответ по статистике по рекламе, где тебе нужно провалиться на 6 этажей в json, чтобы получить статистику по артикулу. Спасибо хоть, что теперь отдают статистику по каждому артикулу, а не как раньше, где статистика была по всей РК. И если в РК добавлено больше одного артикула, то ты не узнаешь, сколько было показов по рекламе у каждого артикула
Но все это, все равно не идет ни в какое сравнение с порой... выдыхаем. Успокаиваемся
Достаточно уже побомбил на этот Озон))
Каждый раз, как заходит речь про Озон, я превращаюсь в бухого батю на пьянке)
denfil
13.12.2025 17:15Вы во многом правы, но часто передергивпете. К примеру транзакции все отдаются. И у меня мой отчёт в один один сходиться с озоновским отчётом из раздела финансы.
KonstantinVladimirtsev
13.12.2025 17:15Сверьтесь по fbs заказам, когда в одной поставке несколько заказов. Они все объединяются в один идентификатор заказа. В поле обработки заказа(для fbo это последняя миля раньше и сейчас это сборка заказа) они отдают стоимость отгрузки заказа на пвз. Списывают они за каждый отдельный заказ, что-то около 20 рублей. А в транзакиях по api отдают просто 20 рублей. И нигде количество товара не указано и посчитать сколько по факту была стоимость невозможно. Тоже самое, если с fbo заказа было несколько товаров. В ЛК они списывают обработку за каждый, а по api, отдают только одно списание
Эквайринг - они меняют идентификатор заказа. Но не всегда. Иногда могут не менять. Иногда, они могут несколько списаний эквайринга объединить в одно списание, одной транзакцией. Просто сгруппировать несколько списаний под один идентификатор, просто удалив последние цифры идентификатора заказа.
Я работаю с селлерами, разные магазины, разные схемы продаж и т.д. и поверьте, они отдают транзакции не полностью. Либо, отдают все, но у остальных меняют идентификатор так, что не сопоставить между собой заказ и эти операции и поэтому я их не вижу при аналитике структуры, при сборке sql запроса
Не успел проверить, но вроде бы они починили - раньше, одно время, они в отчете по статистике по рекламе, они отдавали не полную сумму расходов. В ЛК, в аналитике продвижения, есть 3 цифры расходов. У оплаты за заказ, есть серая цифра расходов. Раньше они её не отдавали точно. Сейчас, вроде, стали отдавать
И да, я передергиваю, для красного словца, но на самом деле, ухожу не сильно далеко от действительности
Я, если что, только за - связаться лично и оказаться неправым и понять, как собирать эти отчеты правильно)
randvell
13.12.2025 17:15Ох намучался я с интеграцией с WB. Я бы сказал, что это худший маркетплейс, если бы не интегрировал Lamoda с совершенно бестолковыми менеджерами и кривой неудобной документацией.
Самая большая прелесть была с реализациями и ценами по заказам, тоже так или иначе на них завязанным. С первым вроде бы все просто - есть заказ, по нему может быть либо выкуп, либо отказ. Либо выкуп и после этого отказ. Но не у ВБ. Порою, без какой либо причины, выкуп проводится как невыкуп, но не через возврат, а через отрицательную реализацию. В итоге, если вслепую завязаться на отчет, то есть шанс увести тоталы в заказах в минус. Со вторым тоже весело - создаем заказ с одной ценой, если это заказ, реализуемый в России, то реальная цена продажи тянется из одного поля, если нет, то из другого. А если совпали звезды, то из третьего. После чего нужно обработать отчет о реализации и посмотреть не решили ли в ВБ применить какую-то магию и поменять цены в заказе. Достаточно часто выходит, что решили. С середины 2024 вроде как появился новый отчет с более адекватным видом, но я, откровенно говоря, даже боюсь к нему прикасаться с учетом того сколько времени ушло чтобы отладить интеграцию.и цифры начали совпадать.
out0f0rder
13.12.2025 17:15Вы хотите сказать, что кривость АПИ их главная проблема?
Это что, только у меня по несколько дней вот такое:
fetchAllGoods Curl error: Operation timed out after 300453 milliseconds with 0 out of 0 bytes receivedИ ответы ТП в стиле "пришлите ответ сервера". А спустя пяток итераций: "были неполадки, исправили".
DigitalSfera Автор
13.12.2025 17:15Я вроде нигде не писал что это "главная" проблема) В вопросе что главнее - кривая архитектура или недоступность, однозначного ответа без контекста я не могу дать. Потому что если апи очень удобный, но ложится на минуту раз в пару часов, или же ложится на полчаса каждый час - это разные вводные. Но и полностью рабочим апи с ущербной архитектурой пользоваться - такое себе. Так что тут вопрос не в "главности", а в конкретных проблемах.
Robastik
13.12.2025 17:15Присоединяюсь ко всем истерикам. Единый брендбук они осилили, а единый подход к проектированию и реализации методов - даже не посягают.
Добавлю на вентилятор: обожают пасхалочки в виде недокументированных полей.
Отдельные лучи поноса озону за невозможность выгрузки рекламы хотя бы раз в час для оперативного реагирования.
И капля конструктива в бочку кринжа: с массовым появлением управляемых браузеров неизбежен переход с недо-апи на ии + мср браузеры.
MrSmitix
С Яндекс Маркетом была похожая история, а именно с их свагером (yandex-market-partner-api на гитхабе) который не соответствует реальности, и на самом деле во многих методах. Хотя находится на первой страницы документации.
Ещё летом отправлял ишью где указал что вот это поле описано в нём, и в доке не верно, так как API возвращает совсем другой ответ. Из-за чего вся валидация, созданного по их свагеру в клиенте падает. И вот пару дней назад пришло уведомление что ишью закрыт. Ишью и возможность их оставлять... Не уверен даже что ошибка исправлена, так как не было времени посмотреть. Скорее всего просто закрыли все что были
Ну ведь понятно что там далеко не дураки работают, но видя такие ошибки на которые на той стороне всем без разницы, кажется обратное. API метод для получения товаров магазина кстати, не что-то специфичное
DigitalSfera Автор
мда, не весело (( у вб вообще на гитхабе ничего нет, но есть их дев-сообщество, где хорошо если на 1 из нескольких десятков вопросов от разрабов придет ответ... у нас проблема что вроде и не дураки, но или осознанно забивают на проблемы разрабов, или не имея опыта работы со своим же детищем, не понимают чего от них хотят
TarMax
Как человек, который работает в продуктовой компании и занимается 3 линией поддержки, рискну предположить, что ребята просто забивают на вопросы и актуальность документации из-за того что сконцентрированы в первую очередь на своих задачах. Ну, вот такой приоритет у них) Это с одной стороны понятно, а с другой...
DigitalSfera Автор
Ну там прикол что документация всегда в достаточно актуальном состоянии. Проблема в самой логике работы некоторых методов; том, что новые методы обычно требуют переписывания кода там, где этого можно было избежать; ну и отсутствии внятных ошибок в некоторых случаях. А с докой все более менее в порядке. Понять-то можно, но ощущение от последних изменений, что там в очередной раз поменялся какой-то руководитель чего-то и решил выпендриться новым "гениальным" решением. Но при этом все вышеперечисленное в статье он не учел, возможно и не думал даже. А это большая проблема и для селлеров и для интеграторов, при любом чихе в апи переписывать систему.