Skip to main content
API /v1 применяет два независимых лимита запросов. Запрос отклоняется, если исчерпан любой из них. Лимит на ключ действует везде, где используется ключ. Лимит на IP-адрес — единственный лимит для неаутентифицированного трафика и второй предел для аутентифицированного трафика.
Ограничения применяются до аутентификации, поэтому запросы с недействительными или отсутствующими учётными данными также учитываются в лимите источника. Точные числовые значения лимитов настраиваются оператором и могут изменяться; контракт ответа, описанный ниже, является стабильным интерфейсом, на который следует ориентироваться при разработке.
Используйте для аутентификации любую из двух форм учётных данных Basic — см. Краткое руководство (apikey:secret или secret:). Укажите в BASE региональный хост организации — см. Регионы.

Ответ 429

Когда лимит исчерпан, API возвращает 429 Too Many Requests с заголовком Retry-After (в секундах) и стандартным телом problem-details:
429 Too Many Requests
В ответе не указано, какой именно лимит исчерпан. Обрабатывайте каждый ответ 429 одинаково: подождите, затем повторите запрос.

Обработка ответов 429

1

Соблюдайте Retry-After

Перед повторной попыткой подождите не менее числа секунд, указанного в заголовке Retry-After. Более ранние повторы лишь впустую расходуют лимит на запросах, которые всё равно будут отклонены.
2

Применяйте экспоненциальную задержку при повторных отказах

Если повторный запрос снова отклонён, увеличьте задержку и добавьте случайный джиттер, чтобы параллельные обработчики не повторяли запросы одновременно. Никогда не сокращайте значение Retry-After сервера под локальное ограничение. Если сервер требует ждать дольше, чем допускает ваш лимит повторных попыток, прекратите попытки и запланируйте выполнение задачи на более позднее время.
3

Сглаживайте частоту запросов

Предпочитайте равномерную частоту запросов всплескам. Для массового чтения используйте максимальный размер страницы (limit=500), чтобы охватить коллекцию меньшим числом запросов — см. постраничную навигацию. Если несколько обходов списков выполняются параллельно (например, таблицы Power BI), поддерживайте умеренную параллельность и соблюдайте Retry-After, чтобы временный ответ 429 не привёл к сбою всего обновления.
Этот пример повторяет запрос только при ответах 429 для запроса GET, не более пяти попыток и с ожиданием не более 60 секунд между попытками. При любых других ошибках выполнение немедленно прекращается. Сетевые тайм-ауты передаются вызывающему коду. Настройте тайм-ауты и лимиты повторных попыток в соответствии с вашей нагрузкой. requests трактует тайм-аут чтения как максимальное время простоя при получении данных, а не как общий предельный срок. Загрузите LIVING_SECURITY_API_KEY из вашего менеджера секретов. Перед запуском этого примера установите requests. Чтобы использовать его, вызовите get_with_retry("/organization").
Python
Не копируйте этот цикл для операций записи. Тайм-аут после записи может означать, что сервер зафиксировал изменение до разрыва соединения. Повторяйте запись только в том случае, если в справочнике по этой операции явно описана идемпотентность, и сохраняйте тот же ключ и те же данные. В остальных случаях перед повторной попыткой сверьте состояние ресурса.

Рекомендуемое расписание обновления

Подбирайте периодичность обновления с учётом лимита на ключ и размера страницы. Полная загрузка истории крупной коллекции — это однократные затраты; для регулярных обновлений предпочитайте инкрементные окна, чтобы каждый запуск оставался значительно ниже лимита. Всегда задавайте limit=500 явно — значение по умолчанию, равное 25, многократно увеличивает число запросов.