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

Столкнулся с рядом трудностей при работе с эндпоинтом 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 обратит внимание на данные предложения. Уверен, они будут полезны многим разработчикам и улучшат экосистему интеграций.

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

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

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

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

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

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

Могу привести наш кейс. У меня запрос от стороннего клиента сделать минимальные изменения в конкретных карточках. Приходит клиент, дает карточки и я сижу жду час по 100 артикулов. Не пойму в чем дело, оказывается на аккаунте 46000 артикулов. Приходится textSearch гонять по 1 артикулу.

1. Почему нет возможности передавать конкретные nmid (при этом есть imtId)? Cursor в моем случае вообще не применим, я не знаю и не хочу знать когда там какой товар был updatedAt. Мне просто нужны nmid, именно nmId, а не imtId. Добавьте поле nmId в фильтр, пожалуйста.

2. Почему нет возможности передавать массив nmid? Сейчас нужно делать 5 запросов и жечь по аккаунту лимиты на 429 в остальных потоках. Добавьте в фильтр массив nmid, пожалуйста.

Все это в разы уменьшит нагрузку на эндпоинт.

Аналогичная проблема, у клиента 500к товаров... Видел решение про последнее обновление, но почему просто не отдавать 1000 товаров в запросе вместо 100? Это усилит нагрузку на каждый запрос, но сократит количество запросов в 10 раз как минимум, если не учитывать еще 429 ошибки