backgroundbackground
Back
Back

Улучшение работы эндпоинта "Список карточек товаров"

Discussion
54135
# Product Management
Discussion

Здравствуйте!

Столкнулся с рядом трудностей при работе с эндпоинтом https://content-api.wildberries.ru/content/v2/get/cards/list, и думаю, что подобные проблемы возникают и у других разработчиков. Хотелось бы озвучить предложения, которые могли бы улучшить удобство использования API и одновременно снизить нагрузку на инфраструктуру Wildberries.

1. Отсутствие сортировки по дате создания карточки

Если карточки создаются вручную через личный кабинет, а затем требуется получить их через API, то невозможно просто выгрузить "новые карточки". Приходится проходить все карточки, чтобы убедиться, что ни одна не была пропущена. Для магазинов с 300 000+ товаров это означает тысячи запросов, что:

  • создаёт нагрузку на API WB,
  • требует обходных решений у разработчиков.

Предложение: добавить параметр сортировки или фильтрации по дате создания карточки.

2. Невозможно получить данные по нескольким артикулам

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

Предложение: добавить возможность передавать массив артикулов (до 100 или 1000) в одном запросе.

Это:

  • значительно снизит количество запросов,
  • упростит работу разработчиков,
  • сократит нагрузку на сервера WB.

3. Нестабильность эндпоинта

Периодически некоторые запросы не выполняются, и требуется повторная отправка. Из-за этого общее количество запросов ещё больше увеличивается, особенно при большом количестве карточек.

Буду рад, если команда WB API обратит внимание на данные предложения. Уверен, они будут полезны многим разработчикам и улучшат экосистему интеграций.

+5
Comment

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

+1
Comment

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

Мы, например, используем settings - sort - ascending (true/false) - это решает проблему 1. Это как раз нормально сделано у WB, в отличие от другого крупного маркетплейса...

0

Replies to the comment

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

0
Comment

2. Невозможно получить данные по нескольким артикулам

Отчего же невозможно? Есть cursor - limit, где как раз задаем сколько карточек хотим )

0

Replies to the comment

Это сколько карточек получать, но мы не можем передать 100/1000 артикулов и получать данные именно по ним. Только по 1 артикулу/баркоду

0

Это сколько карточек получать, но мы не можем передать 100/1000 артикулов и получать данные именно по ним. Только по 1 артикулу/баркоду

А зачем передавать 100 артикулов. Можно воспользоваться пагинацией. Как раз: limit + updatedAt + nmID Мы делаем так. И мы довольны в этом отношении возможностями у WB. Держим у себя в БД данные о товарах. Когда нужно обновить - запрашиваем именно Последние обновленные (один или несколько шагов), пока не дойдём до тех обновленных, последние обновления которых у нас уже были.

0

Передавать 100 артикулов, так как нужны данные только по ним. Это разные задачи, под разные случаи.

0
Comment

И сейчас увидел, что, похоже, в текущей Документации не описаны поля запроса cursor->updatedAt и cursor->nmID

0

Replies to the comment