Ошибка 420 в API Яндекс Маркета требует чтения пояснения: она может означать превышение параллельных запросов либо исчерпание ресурсной квоты. В первом случае помогает управление общей очередью, во втором — ожидание восстановления лимита и сокращение лишней работы. Проверка документации выполнена 19 октября 2026 года.

Установите, какая очередь переполнена

Глобальное ограничение допускает не более четырёх одновременно выполняемых запросов. Для адресов campaigns оно относится к магазину, для businesses — к кабинету. Поэтому четыре потока одного приложения и четыре другого нельзя автоматически считать независимыми. Точная привязка зависит от URL и способа авторизации.

Ресурсная квота описывает другой предел: объём работы за период. Состояние отражается в заголовках X-RateLimit-Resource-Limit, X-RateLimit-Resource-Remaining и X-RateLimit-Resource-Until. Не лечите исчерпанный суточный объём уменьшением пакета с последующей бесконечной отправкой: общий расход от этого может не снизиться.

Составьте карту приложений

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

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

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

Дайте приоритет рабочим операциям

Для собственной интеграции разумно разделить обработку заказов и плановую аналитику. Приоритеты устанавливает продавец: складская операция не должна часами ждать повторного формирования вчерашней таблицы. Это проектное решение, а не обещание отдельной гарантированной полосы API со стороны Маркета.

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

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

Проверьте результат под совместной нагрузкой

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

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