# Лимиты API: как организовать ожидание и повтор запроса

Источник: https://quicklanding.ru/knowledge/api-rate-limit-retry/

Как обрабатывать ограничения API и временные сбои: очередь, ожидание, предел попыток и проверка результата операции.

Интеграция может отлично работать на трёх заявках и начать терять данные при большой выгрузке. Внешний сервис ограничивает количество запросов, временно отвечает ошибкой или не успевает завершить операцию. Решение «повторять до успеха» опасно: оно увеличивает нагрузку и способно создать дубли.

## Узнайте условия конкретного API

![Электронные компоненты на материнской плате](/assets/images/knowledge/api-rate-limit-retry.webp)

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

Проверьте, какие сведения сервис возвращает при ограничении. Например, HTTP 429 может сопровождаться указанием ожидания. Заголовок Retry-After может задавать число секунд или дату. Не предполагайте, что он присутствует в каждом ответе или всегда имеет один формат.

## Разделите ошибки по действиям

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

| Ситуация | Подходящее действие |
| --- | --- |
| Ограничена частота | Учесть условия сервиса и отложить попытку |
| Временная недоступность | Ограниченный повтор после ожидания |
| Неверное поле | Остановить задачу и показать причину |
| Ответ потерян после отправки | Уточнить состояние до повторного создания |

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

## Сохраняйте задачу до внешней отправки

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

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

## Ограничьте попытки и добавьте ожидание

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

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

## Сделайте повторы наблюдаемыми

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

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

## Проверьте ограничение до запуска

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

В QuickLanding такие условия включаем в задание API-интеграции до оценки. Сначала определяем важные операции и допустимые задержки, затем выбираем очередь, повторы и журнал. Это помогает обсуждать надёжность по проверяемому поведению, а не по обещанию «всё синхронизируется».

## Документация и проверка сведений

Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.

- [MDN: ожидание повторного запроса](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After)
- [HubSpot: ограничения использования API](https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines)

## Материалы по соседним задачам

- [API и webhook: как передавать заявки без дублей и тихих потерь](/knowledge/api-webhooks-reliable/)
- [Идемпотентность: как не выполнить одну операцию два раза](/knowledge/api-idempotency/)
- [Разработка API-интеграций](/services/development/api/)

## Частые вопросы

### Можно повторять любой запрос после тайм-аута?

Нет. Для операции создания результат может быть неизвестен. Используйте поддерживаемую идемпотентность или проверку состояния. Простое повторение с новым идентификатором способно создать дубли.

### Что делать, если Retry-After отсутствует?

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

### Нужна очередь небольшой форме?

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

Автор: Владимир Николаев