Comments 25
С Яндекс Маркетом была похожая история, а именно с их свагером (yandex-market-partner-api на гитхабе) который не соответствует реальности, и на самом деле во многих методах. Хотя находится на первой страницы документации.
Ещё летом отправлял ишью где указал что вот это поле описано в нём, и в доке не верно, так как API возвращает совсем другой ответ. Из-за чего вся валидация, созданного по их свагеру в клиенте падает. И вот пару дней назад пришло уведомление что ишью закрыт. Ишью и возможность их оставлять... Не уверен даже что ошибка исправлена, так как не было времени посмотреть. Скорее всего просто закрыли все что были
Ну ведь понятно что там далеко не дураки работают, но видя такие ошибки на которые на той стороне всем без разницы, кажется обратное. API метод для получения товаров магазина кстати, не что-то специфичное
Ишью и возможность их оставлять...
мда, не весело (( у вб вообще на гитхабе ничего нет, но есть их дев-сообщество, где хорошо если на 1 из нескольких десятков вопросов от разрабов придет ответ... у нас проблема что вроде и не дураки, но или осознанно забивают на проблемы разрабов, или не имея опыта работы со своим же детищем, не понимают чего от них хотят
Как человек, который работает в продуктовой компании и занимается 3 линией поддержки, рискну предположить, что ребята просто забивают на вопросы и актуальность документации из-за того что сконцентрированы в первую очередь на своих задачах. Ну, вот такой приоритет у них) Это с одной стороны понятно, а с другой...
Ну там прикол что документация всегда в достаточно актуальном состоянии. Проблема в самой логике работы некоторых методов; том, что новые методы обычно требуют переписывания кода там, где этого можно было избежать; ну и отсутствии внятных ошибок в некоторых случаях. А с докой все более менее в порядке. Понять-то можно, но ощущение от последних изменений, что там в очередной раз поменялся какой-то руководитель чего-то и решил выпендриться новым "гениальным" решением. Но при этом все вышеперечисленное в статье он не учел, возможно и не думал даже. А это большая проблема и для селлеров и для интеграторов, при любом чихе в апи переписывать систему.
Я так скажу. За последние дни они еще выкатили кучу обновлений, и я просто устал вычитывать эти изменения.
При этом Вы говорите про типы акции 8 и 9, а у меня еще и 6 всплыли. и я просто устал читать документацию, в которой абсолютно ничего не написано про типы РК.
Яндекс молчу.
Худшей интеграции я не видел еще. но они меняются.
Утверждать не буду, но вроде как 6-ой тип (это раньше тоже поиск был) перевели внутри их системы в тип 9 уже давно. Может это завершенные давно кампании? Напрягает скорее не поток обновлений, обновления то это хорошо, а то, что надо в каждом разбираться, не сломается ли завтра из-за него вся система, потому что очередное гениальное решение обратной совместимостью не пахнет вообще.
Господи,как же я завидую человеку,который еще не работал с api Озона...
Буквально каждый раз, когда я сажусь сделать что-то с любым из методов, заканчивается все истерикой и вызовом полиции соседями, из-за гневных оров на всю многоэтажку
А кто сказал, что я не работал?)) Озон тоже использую, просто не так активно, как вбшный апи, поэтому наверное не могу такой же объем проблем по ним выдать. Ну у них тоже свои приколы, согласен. Но последние пару лет они стараются если какие то методы и менять, то мягко, чтобы по минимуму пришлось переделывать. По крайней мере насколько я помню, потому что по озону ну было за это время авральных ночей с переписыванием всего. Меня больше всего напрягает асинхронное создание отчетов, даже самых маленьких, но в целом с этим можно жить и их тоже можно понять, почему так сделали.
Немного боли и нытья:
У нас есть 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 Озона придумывает что-то адекватное и логичное, его сразу же бьют палкой по башке
Ахахахах, годно) Я забыл про ID товаров, да, это боль. У меня постоянно расчет прибыли по ним ломается, потому что вроде как product_id должен быть уникален, но как бы ввели то ли сборки то ли что (когда сразу много товаров уходит одним заказом, не помню точно) - продукт айди там дублируется, а вот ску айди разный)) Да, все, я забыл об этих приколах пока бомбил с вб, извиняйте. Ну рекламные отчеты асинхронные к этому я уже привык, json там достаточно понятный. Отчет кстати не может готовится 2-3 часа, после часа подготовки он упадет с ошибкой и можно будет пересоздать. Ограничение на 10 кампаний тоже достаточно тупое. Ну крч да, боли тоже хватает ))((
Просто ощущение, что они скоро начнут донаты просить на сервера, чтобы увеличить лимиты на запросы, потому что им слишком дорого их обслуживать.
И разработчики словно изначально собирали внутреннюю архитектуру дилетанты, а после пришли профессионалы и пытаются на старой, кривой и косой архитектуре строить api исходя из канонов разработки с изоляциями, отдельными сущностями и т.д. вообще не думая о том, что этим будет кто-то пользоваться. И тем более, этим будет пользоваться кто-то, кто не хочет тратить целый день, на то чтобы собрать метод для получения отчета по остаткам
У WB безусловно хватает и своих приколов. Взять тот же метод для получения контента, где вместо нормально пагинации через limit и offset, нам нужно проверять total и передавать cursor. Или тот же ответ по статистике по рекламе, где тебе нужно провалиться на 6 этажей в json, чтобы получить статистику по артикулу. Спасибо хоть, что теперь отдают статистику по каждому артикулу, а не как раньше, где статистика была по всей РК. И если в РК добавлено больше одного артикула, то ты не узнаешь, сколько было показов по рекламе у каждого артикула
Но все это, все равно не идет ни в какое сравнение с порой... выдыхаем. Успокаиваемся
Достаточно уже побомбил на этот Озон))
Каждый раз, как заходит речь про Озон, я превращаюсь в бухого батю на пьянке)
Вы во многом правы, но часто передергивпете. К примеру транзакции все отдаются. И у меня мой отчёт в один один сходиться с озоновским отчётом из раздела финансы.
Сверьтесь по fbs заказам, когда в одной поставке несколько заказов. Они все объединяются в один идентификатор заказа. В поле обработки заказа(для fbo это последняя миля раньше и сейчас это сборка заказа) они отдают стоимость отгрузки заказа на пвз. Списывают они за каждый отдельный заказ, что-то около 20 рублей. А в транзакиях по api отдают просто 20 рублей. И нигде количество товара не указано и посчитать сколько по факту была стоимость невозможно. Тоже самое, если с fbo заказа было несколько товаров. В ЛК они списывают обработку за каждый, а по api, отдают только одно списание
Эквайринг - они меняют идентификатор заказа. Но не всегда. Иногда могут не менять. Иногда, они могут несколько списаний эквайринга объединить в одно списание, одной транзакцией. Просто сгруппировать несколько списаний под один идентификатор, просто удалив последние цифры идентификатора заказа.
Я работаю с селлерами, разные магазины, разные схемы продаж и т.д. и поверьте, они отдают транзакции не полностью. Либо, отдают все, но у остальных меняют идентификатор так, что не сопоставить между собой заказ и эти операции и поэтому я их не вижу при аналитике структуры, при сборке sql запроса
Не успел проверить, но вроде бы они починили - раньше, одно время, они в отчете по статистике по рекламе, они отдавали не полную сумму расходов. В ЛК, в аналитике продвижения, есть 3 цифры расходов. У оплаты за заказ, есть серая цифра расходов. Раньше они её не отдавали точно. Сейчас, вроде, стали отдавать
И да, я передергиваю, для красного словца, но на самом деле, ухожу не сильно далеко от действительности
Я, если что, только за - связаться лично и оказаться неправым и понять, как собирать эти отчеты правильно)
Ох намучался я с интеграцией с WB. Я бы сказал, что это худший маркетплейс, если бы не интегрировал Lamoda с совершенно бестолковыми менеджерами и кривой неудобной документацией.
Самая большая прелесть была с реализациями и ценами по заказам, тоже так или иначе на них завязанным. С первым вроде бы все просто - есть заказ, по нему может быть либо выкуп, либо отказ. Либо выкуп и после этого отказ. Но не у ВБ. Порою, без какой либо причины, выкуп проводится как невыкуп, но не через возврат, а через отрицательную реализацию. В итоге, если вслепую завязаться на отчет, то есть шанс увести тоталы в заказах в минус. Со вторым тоже весело - создаем заказ с одной ценой, если это заказ, реализуемый в России, то реальная цена продажи тянется из одного поля, если нет, то из другого. А если совпали звезды, то из третьего. После чего нужно обработать отчет о реализации и посмотреть не решили ли в ВБ применить какую-то магию и поменять цены в заказе. Достаточно часто выходит, что решили. С середины 2024 вроде как появился новый отчет с более адекватным видом, но я, откровенно говоря, даже боюсь к нему прикасаться с учетом того сколько времени ушло чтобы отладить интеграцию.и цифры начали совпадать.
Вы хотите сказать, что кривость АПИ их главная проблема?
Это что, только у меня по несколько дней вот такое:
fetchAllGoods Curl error: Operation timed out after 300453 milliseconds with 0 out of 0 bytes received
И ответы ТП в стиле "пришлите ответ сервера". А спустя пяток итераций: "были неполадки, исправили".
Я вроде нигде не писал что это "главная" проблема) В вопросе что главнее - кривая архитектура или недоступность, однозначного ответа без контекста я не могу дать. Потому что если апи очень удобный, но ложится на минуту раз в пару часов, или же ложится на полчаса каждый час - это разные вводные. Но и полностью рабочим апи с ущербной архитектурой пользоваться - такое себе. Так что тут вопрос не в "главности", а в конкретных проблемах.
Присоединяюсь ко всем истерикам. Единый брендбук они осилили, а единый подход к проектированию и реализации методов - даже не посягают.
Добавлю на вентилятор: обожают пасхалочки в виде недокументированных полей.
Отдельные лучи поноса озону за невозможность выгрузки рекламы хотя бы раз в час для оперативного реагирования.
И капля конструктива в бочку кринжа: с массовым появлением управляемых браузеров неизбежен переход с недо-апи на ии + мср браузеры.
Через браузер можно автоматизировать, но по идее это интеграция, а за нее может прилететь штраф, если вб спалит. Написать то не сложно, вопрос ответственности за последствия. У вас есть опыт использования?
Опыта нет, только планы.
Если используется настоящий браузер, который невозможно отличить от настоящего и поведение не дудосное, то как им в голову придет, что это не чел?
Легко, если нет прогрева и истории
Ну фреймворки для автоматизации типа селениума обычно настраивают браузер не прям похоже на обычного пользователя. К ним есть конечно разные способы сделать настройки более человекоподобными, но кто знает к чему вб может привязаться? Заголовки браузера, фингерпринты, айпишники (не запускать же все процессы с боевого серверного айпи, так вообще сразу все спалится). Вопрос то в том что цена ошибки - не ответ 401, а штраф для кабинета селлера, в котором это будет юзаться
селениум в прошлом, появились варианты управления ии реальным браузером
Wildberries API: версии есть, стабильности — нет