Автоматизация склада

Маркетплейс вернул 429. Как обновить остатки без пропусков

Как синхронизировать остатки между 1С и маркетплейсом, учитывать лимит API, повторять сбои и сверять данные на витрине.

Специалист проверяет остаток товара на складском терминале

Откуда берётся расхождение остатков

В 1С по товару осталась одна штука. Сотрудник продал её в рознице, а интернет-магазин продолжает принимать заказы. Обновление ушло в обмен, но часть запросов маркетплейс отклонил с кодом HTTP 429. Без статуса по каждой позиции менеджер замечает проблему уже при сборке заказа.

Что значит ошибка 429 Too Many Requests

Ошибка 429 Too Many Requests по-русски означает «слишком много запросов». Запрос — это одно обращение программы к маркетплейсу, например «обнови остаток этого товара до пяти штук». Площадка ограничивает число таких обращений за определённое время, чтобы справляться с нагрузкой.

Допустим, площадка принимает до 30 запросов в минуту. Если программа отправит 40 подряд, часть может получить ответ 429. На витрине тогда может остаться старое количество. Программе нужно сделать паузу, повторить нужные обновления и проверить, дошли ли они. Числа в примере условные, у каждой площадки свои лимиты.

В руководстве от 10 ноября 2026 года команда n8n показывает два способа пакетной обработки: обход записей с паузами и объединение нескольких записей в один запрос, если это поддерживает площадка. В нашем сценарии такой обмен можно проверить на связке 1С, интеграция и витрина. Лимиты и допустимый размер пакета берём из документации конкретного метода API.

Приёмка товара и сканирование штрихкода
Приёмка товара и сканирование штрихкода
Путь остатка до витрины. 1С фиксирует количество и версию. Очередь группирует обновления. Витрина подтверждает остаток
Путь остатка до витрины

Как повторять обновления после ответа 429

Сначала определите, по какой комбинации система хранит остаток. Для маркетплейса это обычно магазин, склад и идентификатор товара. В журнал обмена записываем эту комбинацию, количество, время изменения и версию записи. Для каждой позиции сохраняем результат: ожидает отправки, принята площадкой, подтверждена сверкой или требует внимания. Если пакетный ответ содержит результаты по отдельным позициям, используем эти статусы при повторе.

  1. Разделите очередь на пакеты и распределите запросы по времени с учётом общего лимита. Если несколько задач используют один доступ к API, их трафик учитываем вместе.
  2. При 429 прочитайте Retry-After, если площадка его прислала. Заголовок может содержать число секунд или дату следующей допустимой попытки. При отсутствии заголовка используйте увеличивающуюся паузу с небольшим случайным разбросом и ограничением числа попыток.
  3. Перед повтором проверьте, какая версия остатка сейчас актуальна. Если после нуля пришло новое поступление, отправляем последнее значение. Это защищает витрину от запоздалой записи старого остатка.
  4. Если результат отправки неизвестен после тайм-аута, проверьте статус операции или прочитайте остаток на площадке. Там, где API поддерживает ключ идемпотентности, повтор той же операции отправляйте с тем же ключом.
Упаковка последней доступной единицы товара
Упаковка последней доступной единицы товара
Что делать после ответа 429. Прочитать Retry-After или рассчитать паузу. Сверить актуальную версию остатка. Отправить только нужные обновления
Что делать после ответа 429

Когда считать обмен выполненным

Ответ API может означать, что площадка приняла пакет в обработку. Подтверждение для бизнеса — актуальное количество в отчёте площадки или в методе чтения остатков после окна обработки. Сверка по расписанию помогает найти позиции, для которых площадка приняла обновление с задержкой, вернула ошибку по отдельному складу или сопоставила другой артикул.

Начните с трёх случаев. Товар ушёл в ноль. Остаток изменился дважды подряд. Площадка приняла часть пакета, а остальным позициям вернула ошибку. В каждом случае в отчёте нужно увидеть ожидаемое количество, подтверждённое количество, время последней сверки и ответственного за исключение. Возврат к ручной обработке нужен, если автоматические попытки закончились или идентификатор товара расходится между системами.

Сверка остатков в складском офисе
Сверка остатков в складском офисе
Сверка после отправки. Прочитать фактический остаток. Сравнить товар, склад и количество. Расхождение записать в журнал
Сверка после отправки

Что проверить на пилоте

Возьмите одну витрину, один склад и выборку ходовых позиций. Зафиксируйте, сколько времени проходит от изменения остатка в 1С до подтверждения на площадке. Отдельно посчитайте долю обновлений, подтверждённых в согласованный срок, число повторов и число продаж при нулевом остатке. Сравните обычный день и период высокой нагрузки. Для событий с задержкой храните время изменения и время подтверждения, чтобы отделить ожидание в очереди от задержки самой площадки.

Калькулятор ниже даёт оценку длительности отправки при равномерном темпе. В расчёте можно оставить запас на повторы. Время обработки на площадке и её паузы после 429 оценивайте по журналу пилота. Для проектирования обмена пригодится также разбор проверок фактического результата интеграции.

Видео по теме

Обработка пакетов показана с 16:08, пауза между запросами — с 25:03.

Обработка данных порциями в n8n · Игорь Зуевич