Если вы хоть раз переносили каталог на Wildberries через API или пользовались сервисами автоматизации, вы наверняка видели ошибку HTTP 429 — Too Many Requests. Она означает, что вы превысили лимит запросов, и площадка временно отказывается вас обслуживать. Разберём, почему это происходит, чем опасна ошибка именно при переносе карточек и как построить работу, чтобы с ней не сталкиваться.
Что такое лимиты API Wildberries
WB, как и любой крупный сервис, ограничивает частоту обращений к своему API, чтобы защитить инфраструктуру. Лимиты различаются по группам методов: у контент-API (создание и редактирование карточек, загрузка медиа), у API цен и у API статистики — свои квоты, обычно выраженные в запросах в минуту. Точные значения периодически меняются — актуальные всегда смотрите в официальной документации WB.
При превышении лимита API возвращает статус 429. В зависимости от метода может добавляться заголовок с временем, через которое можно повторить запрос, но рассчитывать на него вслепую не стоит.
Почему 429 чаще всего возникает при переносе карточек
Перенос каталога — это пиковая нагрузка: за короткое время вы делаете в разы больше запросов, чем при обычной работе. Типичные сценарии-ловушки:
- Агрессивный поллинг статуса карточки. Классическая ошибка: создали карточку на WB и сразу начали каждые пару секунд проверять, готова ли она к загрузке фото. Карточки WB индексируются с задержкой — минуты, иногда дольше. Десятки проверок на каждую карточку, умноженные на сотни карточек, — и вот вы уже в 429-шторме, причём полезных запросов среди них меньшинство.
- Параллельная загрузка без ограничения. Запустить создание 200 карточек одновременными потоками — верный способ упереться в лимит за первую же минуту.
- Ретраи без паузы. Получили ошибку и тут же повторили запрос — лимит не «остывает», а 429 начинают приходить пачками.
- Несколько инструментов на одном токене. Лимит считается на токен, а не на приложение. Если репрайсер, аналитика и перенос работают с одним ключом одновременно, их нагрузка суммируется.
Важно: лимит WB считается на токен, а не на приложение. Репрайсер, аналитика и перенос на одном ключе делят одну квоту — и 429 может вызвать любой из них, «повесив» остальные.
Чем опасна ошибка 429
Сама по себе 429 не страшна — это не блокировка аккаунта, а временный отказ. Но последствия при переносе неприятные:
- часть карточек создаётся, часть — нет, и каталог оказывается перенесён «рваным»;
- фото и цены не догружаются на уже созданные карточки — они висят пустыми;
- если скрипт не ведёт учёт состояния, при перезапуске легко создать дубли карточек.
Как работать с API, чтобы не получать 429
Рабочие приёмы сведены в таблицу, а ниже разберём каждый подробнее:
| Приём | Как работает | Когда применять |
|---|---|---|
| Паузы между запросами | Последовательная обработка с задержкой 300–500 мс | Всегда при массовых операциях |
| Экспоненциальный backoff | Повтор через нарастающую паузу: 1, 2, 4 секунды | При ответах 429, 5xx и сетевых сбоях |
| Отложенная очередь | Задача на дозагрузку ставится с задержкой вместо поллинга | Ожидание индексации карточек WB |
| Разделение токенов | Отдельный токен для каждой системы | Если на одном ключе работает несколько инструментов |
Паузы между запросами
Даже простая пауза в 300–500 мс между запросами радикально снижает нагрузку. При массовых операциях последовательная обработка с паузами почти всегда надёжнее параллельной.
Экспоненциальный backoff при ретраях
Правильная реакция на 429 (а также на сетевые сбои и 5xx): повторить запрос через нарастающую паузу — например, через 1, 2, 4 секунды, ограничив число попыток. Это стандартная практика, и её легко реализовать в любом языке.
Не поллить, а откладывать
Вместо постоянной проверки «готова ли карточка» используйте отложенную очередь: создали карточку — поставили задачу на загрузку фото через несколько минут; если карточка ещё не проиндексирована — отложили задачу с увеличенной паузой. Именно так устроен перенос в recards.ru: после создания карточки фото и цена уходят в очередь повторных попыток с нарастающим интервалом (от нескольких минут до нескольких часов), и ни один лишний запрос не тратится на бессмысленный поллинг.
Разделяйте токены по задачам
Если позволяет регламент WB, заведите отдельные токены для разных систем — так репрайсер не помешает переносу, и вы точнее будете понимать, кто именно съедает лимит.
Что делать, если 429 уже идут потоком
- Остановите процесс, генерирующий запросы. Дальнейшие попытки только продлевают шторм.
- Подождите несколько минут — лимиты обычно оконные и сбрасываются.
- Проверьте, какие операции успели выполниться (по журналу или по факту наличия карточек), чтобы не создать дубли.
- Перезапустите перенос с паузами и backoff, начав с места остановки, а не с нуля.
Правило: прежде чем перезапускать перенос после 429-шторма, сверьтесь с журналом операций и начинайте с места остановки. Перезапуск «с нуля» почти гарантированно создаст дубли карточек.
Вывод: HTTP 429 на Wildberries — это не баг и не блокировка, а сигнал перестроить нагрузку. Паузы, экспоненциальные ретраи и отложенные очереди вместо поллинга решают проблему полностью. Если не хотите заниматься этим сами — используйте инструменты, где эта логика уже встроена.