Пояснення лімітів API криптобірж
1. Що означають “ліміти API”
Ліміти API на папері прості. Вони визначають максимальну кількість запитів, яку біржа прийме в межах певного проміжку часу — наприклад, 1 секунди, 1 хвилини або 1 години. У цьому й полягає суть пояснення лімітів API криптобірж.
Не плутайте ліміти з комісіями. Комісія — це гроші, які стягують за угоду, виведення коштів або тарифний рівень сервісу. Ліміт — це правило трафіку. Якщо ваш клієнт надсилає 200 запитів за хвилину, а біржа дозволяє лише 120, 121-й запит може не пройти, навіть якщо ваш акаунт безкоштовний.
Ліміти також відрізняються від рівнів акаунтів. Деякі біржі дають більші ліміти верифікованим користувачам, маркет-мейкерам або платним планам, але ліміт усе одно існує. Один рівень може дозволяти 10 запитів за секунду, а інший — 50. Біржа все одно проводить межу, і саме тому ліміти API криптобірж потрібно враховувати ще на етапі проєктування інтеграції.
Якщо пояснити практично: ліміти — це правила входу для API. Вам можуть дозволити доступ, але не всім одразу. У завантажені дні це особливо важливо.
2. Навіщо біржі використовують ліміти
Біржі використовують ліміти з трьох простих причин: захистити інфраструктуру, зменшити зловживання та зберегти стабільність систем під час піків трафіку. Ринок може рухатися дуже швидко за 30 секунд, а потік скриптів одночасно навантажує книги ордерів, перевірки балансу та цінові стрічки. Якщо один клієнт надсилає занадто багато запитів, це відчувають усі.
Є й аспект справедливості. Без лімітів один агресивний бот міг би «бомбити» публічні ендпоїнти й витісняти менших користувачів. Це не теорія; така проблема виникає, коли новий лістинг або різкий розпродаж піднімає обсяг запитів вище звичного рівня.
Деякі ліміти існують, щоб зупиняти скрапінг, зловживання або випадкові цикли. Поганий цикл може надіслати той самий запит 500 разів, перш ніж хтось це помітить. Біржа бачить шторм, а не випадковість.
Втім, ліміти — це не лише захист. Вони допомагають біржам підтримувати актуальність ринкових даних і чутливість торгових систем, коли трафік зростає. Стабільний API викликатиме більше довіри, ніж той, що «ламається» під раптовим напливом.
3. Як вимірюють ліміти
Більшість бірж вимірюють ліміти в запитах за секунду або за хвилину. Інші використовують змішану систему: невеликий ліміт на секунду і більший — на хвилину. Біржа також може призначати різну вагу різним ендпоїнтам. Простий запит ціни може рахуватися як 1 одиниця, тоді як розміщення ордера або запит історії — як більше.
Часто ліміти залежать від ендпоїнта. Публічний ендпоїнт котирувань може дозволяти більше запитів, ніж приватний ендпоїнт балансу. Окремі ліміти для публічних і автентифікованих запитів також трапляються часто.
Деякі API дозволяють короткі «викиди» трафіку. Це означає, що ви можете надіслати невеликий кластер запитів вище стабільного темпу на кілька секунд, якщо середнє значення все одно вписується в правило. Інші працюють жорстко й рівно, без жодного запасу на burst. Різниця впливає на те, як ви пишете клієнт і як працюють rate limit в API бірж у реальних сценаріях.
Шукайте одиницю виміру, вікно та вагу. Саме ці три числа розповідають основну історію. Сторінки, де просто написано “rate limited”, недостатньо.
4. Де ліміти проявляються в реальних сценаріях
Найперше ліміти проявляються в звичайних задачах. Трейдер, який оновлює ціни кожні 2 секунди, може швидко впертися в межу, якщо застосунок одночасно перевіряє 20 ринків. Розробник, який синхронізує баланси кожні 5 секунд, спочатку може не мати проблем, а потім раптово побачити помилки, коли список гаманців зросте з 3 активів до 30.
Розміщення ордерів — ще одна точка тиску. Бот, який тестує сигнали, скасовує застарілі ордери та повторно надсилає нові, може дуже швидко витратити свій ліміт запитів, особливо під час волатильності. Ще хвилину тому система здавалася спокійною. А потім через 12 тиков ціни — уже ні.
Історичні завантаження ще легше недооцінити. Вивантаження 90 днів свічок, історії угод або виконань часто означає тисячі запитів, і кожен із них конкурує з живим трафіком, якщо тільки біржа не пропонує batch-ендпоїнт. Якщо API повертає лише 100 рядків за виклик, математика швидко стає неприємною.
Пулінг — це прихований податок на час, а не на гроші. Дашборд, який перевіряє п’ять ендпоїнтів щосекунди, може виглядати безпечним під час тестування, а потім перевантажити ліміт, щойно реальні користувачі почнуть входити в систему. Саме тому багато команд переходять із polling на websockets після першого складного місяця.
5. Типові попередження та збої
Найочевидніший сигнал — це помилка HTTP, часто статус 429, що означає забагато запитів. Деякі біржі повертають чітке повідомлення. Інші дають загальну помилку й очікують, що клієнт прочитає заголовки. Не найприємніше, але доволі поширено; у практиці це часто виглядає як помилка 429 на криптобіржі.
Ще один наслідок — тимчасове обмеження швидкості. API може почати повільніше відповідати ще до того, як почне відхиляти запити. Ви надсилаєте запит і чекаєте 1,5 секунди на відповідь, яка раніше займала 120 мілісекунд. Це затримка — попередження перед повним блокуванням.
Деякі платформи застосовують бан-окно після повторних порушень. Бан може тривати 30 секунд, 5 хвилин або довше. У важких випадках біржа може заблокувати IP-адресу або API-ключ. Якщо бот бездумно повторює спроби, покарання лише посилюється.
Відхилення ордерів також можуть траплятися без акуратного повідомлення про ліміт. Торговий запит може не пройти, тому що клієнт уже використав дозволений burst-ліміт, хоча той самий акаунт і далі може отримувати публічні дані. Така невідповідність часто збиває команди з пантелику під час першої інтеграції.
6. Як читати правила лімітів біржі
Починайте з документації, але не зупиняйтеся на першій таблиці. Шукайте вагу ендпоїнтів, правила cooldown і примітки про винятки. На сторінці може бути написано “10 запитів за секунду”, а далі дрібним шрифтом зазначено, що торгові ендпоїнти рахуються як вага 5 кожен. Це дуже змінює реальну пропускну здатність.
Заголовки мають значення. Багато бірж надсилають у відповіді rate-limit headers, і вони часто показують, скільки запитів залишилося, коли відбудеться скидання або чи поточний виклик використав додаткову вагу. Якщо документація туманна, заголовки зазвичай менш туманні.
Звертайте увагу на приховані винятки. Публічні ринкові дані можуть мати одне правило, а приватні торгові запити — інше. У websocket-з’єднань теж можуть бути окремі ліміти на кількість з’єднань. Якщо прочитати лише перший абзац, можна пропустити саме той пункт, який потім зашкодить.
Команди часто тримають простий чекліст перед інтеграцією. Якщо вам потрібен ширший список для підготовки, стаття про чекліст безпеки криптобіржі стане корисним доповненням, бо помилки з лімітами й помилки безпеки часто з’являються разом, коли API-ключ виявляється розкритим або використовується неправильно.
Також звертайте увагу на формулювання в документації. Короткі фрази можуть приховувати реальні обмеження. Якщо на сторінці написано “fair use”, попросіть точне число. Якщо написано “може змінюватися”, запитайте, хто саме змінює й як часто. Це важливо до запуску в продакшн, а не після збою.
7. Терміни, які варто знати
Throttle означає, що біржа навмисно сповільнює ваші запити. Це ще не збій, але вже близько. Ви все ще можете отримувати відповіді, просто пізніше, ніж зазвичай.
Quota — це загальний доступний обсяг на певний період. Якщо квота становить 100 запитів за хвилину, ця цифра скидається, коли закривається хвилинне вікно. Квота — це бюджет. Витрачайте його обережно.
Burst allowance — це короткочасний додатковий запас, який може надати API. Ривок у 20 запитів може бути допустимим, навіть якщо стабільний темп — 5 за секунду. Але є нюанс: середнє значення все одно має вкладатися в правило.
Backoff — це пауза перед наступною спробою. Клієнт, який чекає 250 мілісекунд, потім 500 мілісекунд, а потім 1 секунду, поводиться як терпляча людина. Клієнт, який повторює запит миттєво, поводиться як зламаний.
Ban window — це період, протягом якого біржа блокує нові запити після порушення. Weighted requests — це виклики, які рахуються не як 1 одиниця, а як більше. Якщо один ендпоїнт має вагу 10, то 10 таких викликів можуть витратити той самий ліміт, що й 100 легких запитів. Саме така деталь ламає бота о 3-й ранку.
8. Приклади: типові сценарії лімітів
Приклад 1: застосунок для перевірки цін. Припустімо, що застосунок відстежує 8 пар і оновлює їх кожні 5 секунд. Це звучить легко, але якщо кожне оновлення звертається до окремого публічного ендпоїнта, а біржа дозволяє лише 10 запитів за секунду, то застосунок може залишатися в межах, доки не приєднається більше користувачів і той самий сервер не почне обслуговувати 50 сесій. Тоді ліміт стає помітним.
Приклад 2: торговий бот. Бот перевіряє сигнали, розміщує ордери, скасовує застарілі ордери й підтверджує виконання. Якщо кожна дія використовує автентифіковані ендпоїнти з вищою вагою, бот може досягти ліміту вже після кількох швидких циклів. Обережний бот використовує кешований стан, менше перевірок балансу та затримку між повторними спробами, яка зростає після кожної помилки.
Приклад 3: ресурсомістке завантаження історії. Дослідницький скрипт, який завантажує 180 днів даних свічок, може впертися в ліміти задовго до завершення. Якщо біржа повертає лише 200 рядків за запит, завданню може знадобитися сотні викликів. Краще розбивати завантаження по днях, робити паузи між блоками й продовжувати з останньої коректної часової мітки після збою.
Якщо ви порівнюєте платформи для будь-якого з цих сценаріїв, вибір біржі має не менше значення, ніж код. Практичний гайд на кшталт як обрати криптобіржу допоможе, коли ви вирішуєте, чи підходить дизайн API вашому робочому процесу, а не лише чи гарно виглядає торговий інтерфейс.
Є й другий тип прикладу, який варто згадати: API, що виглядає акуратно, але все одно поводиться погано під навантаженням. Деякі проєкти чудово працюють у sandbox, а потім ламаються на живих ендпоїнтах, бо правила лімітів у продакшні суворіші. Саме тому тестових даних ніколи не буває достатньо.
Ще одна практична порада. Якщо ви намагаєтеся захистити клієнта від банів, матеріал про як перевірити криптовалютну біржу допоможе з’ясувати, чи публікує платформа чіткі правила, контакти підтримки та послідовну поведінку API, перш ніж довіряти їй живий трафік.
Для читачів, які створюють боти або дашборди, найкраще рішення зазвичай не “надсилати швидше”, а “надсилати менше”. Кешуйте результати на 3 секунди, прибирайте дублікати запитів і не запитуйте той самий баланс двічі в одному циклі. Така проста дисципліна зберігає спокій API й робить логи читабельними.
І останнє зауваження: якщо сторінка документації настільки нечітка, що ви не можете зрозуміти, чи коштує один запит 1 одиницю чи 5, сприймайте це як попередження, а не як загадку. Попросіть підтримку назвати точний ліміт, вікно скидання та штраф за перевищення. Це не декоративні деталі; саме вони визначають, чи переживе інтеграція свою першу завантажену годину.
