Skip to main content
API /v1 застосовує два незалежні ліміти запитів. Запит відхиляється, якщо вичерпано будь-який із них. Ліміт на ключ діє скрізь, де використовується цей ключ. Ліміт на IP-адресу є єдиним лімітом для неавтентифікованого трафіку та другою межею для автентифікованого трафіку.
Ліміти застосовуються до автентифікації, тому запити з недійсними або відсутніми обліковими даними також враховуються в ліміті джерела. Точні числові значення лімітів налаштовує оператор, і вони можуть змінюватися; контракт відповіді, наведений нижче, є стабільним інтерфейсом, на який слід орієнтуватися.
Виконуйте автентифікацію за допомогою будь-якого з двох варіантів облікових даних Basic — див. Quickstart (apikey:secret або secret:). Вкажіть у BASE регіональний хост організації — див. Regions.

Відповідь 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), щоб охопити колекцію меншою кількістю запитів — див. pagination. Якщо паралельно виконується кілька обходів списків (наприклад, таблиць Power BI), підтримуйте помірну паралельність і враховуйте Retry-After, щоб тимчасова відповідь 429 не призвела до збою всього оновлення.
Цей приклад повторює лише відповіді 429 для запиту GET, не більше ніж п’ять спроб і з очікуванням не довше 60 секунд між спробами. У разі інших помилок він негайно зупиняється. Тайм-аути мережі передаються викликачу. Налаштуйте тайм-аути та бюджети повторних спроб відповідно до вашого навантаження. requests трактує тайм-аут читання як максимальний час простою під час отримання даних, а не як загальний крайній термін. Завантажте LIVING_SECURITY_API_KEY зі сховища секретів. Установіть requests перед запуском цього прикладу. Викличте get_with_retry("/organization"), щоб скористатися ним.
Python
Не копіюйте цей цикл для операцій запису. Тайм-аут після запису може означати, що сервер зафіксував зміну до розриву з’єднання. Повторюйте запис лише тоді, коли в довідці до цієї операції прямо задокументовано ідемпотентність, зберігаючи той самий ключ і те саме навантаження. В іншому разі перед повторною спробою звірте стан ресурсу.

Рекомендований графік оновлення

Підбирайте періодичність оновлення з урахуванням ліміту вашого ключа та розміру сторінки. Повне історичне завантаження великої колекції є одноразовими витратами; для регулярних оновлень надавайте перевагу інкрементним вікнам, щоб кожен запуск залишався значно нижчим за ліміт. Завжди явно задавайте limit=500 — значення за замовчуванням 25 збільшує кількість запитів.