25 сентября Ozon сообщил о появлении заголовков для управления ограничениями частоты запросов в Seller API. Ранее, в июне, дополнительные сведения при ответе 429 были объявлены для метода вывода товаров из архива. Обновления дают разработчикам больше информации для настройки нагрузки со стороны интеграций.

Зачем интеграции читать заголовки

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

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

Как распределять очередь запросов

Разделите операции по срочности и цене задержки. Обновление справочника можно выполнять реже, чем обработку важного рабочего события. Полная историческая выгрузка обычно терпит паузу, тогда как очередь повседневных задач требует отдельного внимания. Такое разделение помогает использовать доступный ресурс осмысленно, не пытаясь запускать все процессы одновременно.

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

Что делать после ответа 429

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

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

Как оценить результат настройки

Наблюдайте за долей ответов 429, временем ожидания задач и возрастом последнего успешно обновлённого набора данных. Снижение числа ошибок само по себе не доказывает улучшение: можно уменьшить нагрузку настолько, что важные сведения начнут сильно запаздывать. Нужен баланс между доступными лимитами и реальными требованиями магазина к свежести данных.

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