Пояснение к лимитам запросов API на криптобиржах
1. Что означают «лимиты запросов API»
Лимиты запросов API на криптобиржах на бумаге устроены просто. Они показывают, сколько запросов биржа примет за заданный промежуток времени — например, за 1 секунду, 1 минуту или 1 час. В этом и состоит суть того, что подразумевается под пояснением к лимитам запросов API на криптобиржах.
Не путайте лимиты запросов с комиссиями. Комиссия — это деньги, которые взимают за сделку, вывод или тарифный уровень. Лимит запросов — это правило для трафика. Если ваш клиент отправит 200 запросов за минуту, а биржа разрешает только 120, 121-й запрос может не пройти, даже если у вас бесплатный аккаунт.
Лимиты также отличаются от уровней аккаунта. На некоторых биржах верифицированным пользователям, маркетмейкерам или платным тарифам дают более высокие лимиты, но сам лимит при этом никуда не исчезает. Один уровень может разрешать 10 запросов в секунду, а другой — 50. Биржа всё равно проводит границу.
Удобно думать об этом так: лимиты запросов — это правила входа для API. Вас могут пустить, но не всех и не сразу. В загруженные дни это особенно важно.
2. Зачем биржи используют лимиты запросов
Биржи используют лимиты запросов по трём простым причинам: защитить инфраструктуру, снизить злоупотребления и поддерживать стабильность систем во время всплесков трафика. Рынок может резко двигаться за 30 секунд, и поток скриптов одновременно нагружает ордербуки, проверки баланса и ценовые ленты. Если один клиент отправляет слишком много запросов, это чувствуют все.
Есть и вопрос справедливости. Без ограничений один агрессивный бот мог бы забивать публичные конечные точки и вытеснять менее крупных пользователей. Это не теория — такие проблемы обычно проявляются, когда новый листинг или резкая распродажа поднимает объём запросов выше обычного.
Некоторые лимиты нужны, чтобы остановить скрейпинг, злоупотребления или случайные циклы. Плохой цикл может отправить один и тот же запрос 500 раз, прежде чем кто-то это заметит. Для биржи это выглядит как шторм, а не как ошибка.
При этом лимиты нужны не только для защиты. Они помогают биржам поддерживать свежесть рыночных данных и отзывчивость торговых систем при росте нагрузки. Стабильный API вызывает больше доверия, чем тот, который ломается при внезапном наплыве.
3. Как измеряются лимиты запросов
Большинство бирж измеряют лимиты в запросах в секунду или в запросах в минуту. Другие используют смешанную систему: небольшой лимит на секунду и более высокий — на минуту. Биржа также может назначить разный вес разным конечным точкам. Простая проверка цены может считаться за 1 единицу, а размещение ордера или запрос истории — за большее количество.
Часто встречаются лимиты, зависящие от конкретной конечной точки. Публичная лента котировок может разрешать больше запросов, чем приватная конечная точка баланса. Раздельные лимиты для публичных и авторизованных запросов тоже встречаются нередко.
Некоторые API допускают короткие всплески. Это означает, что вы можете на несколько секунд отправить небольшой кластер запросов выше устойчивого уровня, если среднее значение остаётся в пределах правила. Другие строгие и ровные, без какого-либо запаса на всплеск. Разница влияет на то, как вы пишете клиент.
Ищите единицу измерения, временное окно и вес. Эти три числа рассказывают почти всю историю. Страницы, где написано только «есть ограничение по запросам», недостаточно.
4. Где лимиты проявляются в реальных сценариях
Лимиты сначала проявляются в обычных задачах. Трейдер, обновляющий цены каждые 2 секунды, быстро упрётся в потолок, если приложение проверяет сразу 20 рынков. Разработчик, синхронизирующий балансы каждые 5 секунд, поначалу может не замечать проблем, а потом внезапно увидеть ошибки, когда список кошельков вырастет с 3 активов до 30.
Размещение ордеров — ещё одна точка давления. Бот, который тестирует сигналы, отменяет устаревшие заявки и отправляет новые, может очень быстро расходовать бюджет запросов, особенно во время волатильности. В одну минуту система кажется тихой. А через 12 ценовых тиков уже нет.
Исторические догрузки ещё легче недооценить. Получение 90 дней свечей, истории сделок или исполнений часто означает тысячи запросов, и каждый из них конкурирует с живым трафиком, если только биржа не предлагает пакетную конечную точку. Если API возвращает по 100 строк за вызов, математика очень быстро становится неприятной.
Опрос по расписанию — это скрытый налог на время, а не на деньги. Панель, которая проверяет пять конечных точек каждую секунду, на тестах выглядит безобидно, а потом перегружает лимит, как только реальные пользователи входят в систему. Поэтому многие команды после первого тяжёлого месяца переходят с опроса на вебсокеты.
5. Частые предупреждающие признаки и сбои
Самый очевидный признак — HTTP-ошибка, часто статус 429 на криптобирже, означающий слишком много запросов. Некоторые биржи возвращают понятное сообщение. Другие дают общий сбой и ожидают, что клиент сам прочитает заголовки. Неудобно, но это обычная практика.
Ещё один вариант — временное замедление. API может сначала замедлять ответы, а уже потом начинать отклонять запросы. Вы отправляете запрос и ждёте 1,5 секунды ответ, который раньше приходил за 120 миллисекунд. Такое замедление — предупреждение перед отключением.
Некоторые платформы вводят окно бана после повторных нарушений. Бан может длиться 30 секунд, 5 минут или дольше. В тяжёлых случаях биржа может заблокировать IP-адрес или API-ключ. Если бот продолжает бездумно повторять попытки, наказание становится жёстче.
Отклонения ордеров тоже могут происходить без аккуратного сообщения о лимите. Торговый запрос может не пройти, потому что клиент уже израсходовал разрешённую квоту всплеска, хотя этот же аккаунт всё ещё может получать публичные данные. Такое несоответствие часто сбивает команды с толку на первой интеграции.
6. Как читать правила лимитов биржи
Начните с документации, но не останавливайтесь на первой таблице. Ищите веса конечных точек, правила пауз между запросами и примечания об исключениях. На странице может быть указано «10 запросов в секунду», а ниже — тихо добавлено, что ордерные конечные точки считаются с весом 5 каждая. Это сильно меняет реальную пропускную способность.
Заголовки тоже важны. Многие биржи отправляют в ответе заголовки с информацией о лимитах, и по ним часто видно, сколько запросов осталось, когда произойдёт сброс или был ли текущий вызов более тяжёлым по весу. Если документация расплывчата, заголовки обычно говорят более прямо.
Следите за скрытыми исключениями. Публичные рыночные данные могут подчиняться одному правилу, а приватные торговые запросы — другому. Для вебсокет-подключений тоже могут существовать отдельные лимиты соединений. Если прочитать только первый абзац, можно пропустить как раз ту часть, которая потом создаст проблемы.
Перед интеграцией команды часто держат простой чек-лист. Если вам нужен более широкий список перед запуском, статья о чек-листе безопасности криптобиржи будет полезным дополнением, потому что ошибки с лимитами и ошибки безопасности часто появляются вместе, когда API-ключ оказывается раскрыт или используется неправильно.
Также обращайте внимание на формулировки в документации. Короткая фраза может скрывать реальные ограничения. Если на странице написано «разумное использование», спросите точное число. Если сказано «может изменяться», уточните, кто именно меняет правила и как часто. Ответ важен до выхода в продакшен, а не после сбоя.
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 может выглядеть чисто, но всё равно плохо вести себя под нагрузкой. Некоторые проекты отлично работают в песочнице, а на живых конечных точках начинают падать, потому что в продакшене правила лимитов жёстче. Поэтому одних тестовых данных никогда не хватает.
Ещё одна практическая мысль. Если вы пытаетесь защитить клиента от банов, статья о как проверить криптовалютную биржу поможет убедиться, публикует ли платформа понятные правила, контакты поддержки и последовательное поведение API, прежде чем доверять ей живой трафик.
Для тех, кто строит ботов или панели мониторинга, самое аккуратное решение обычно не в том, чтобы «отправлять быстрее», а в том, чтобы «отправлять меньше». Кэшируйте результаты на 3 секунды, убирайте дублирующиеся вызовы и не запрашивайте один и тот же баланс дважды за один цикл. Такая простая дисциплина сохраняет API спокойным, а логи — читаемыми.
И последнее замечание: если страница документации настолько расплывчата, что вы не можете понять, стоит один запрос 1 единицу или 5, воспринимайте это как предупреждение, а не как загадку. Спросите у поддержки точный лимит, окно сброса и штраф за превышение. Это не декоративные детали; от них зависит, переживёт ли интеграция свой первый загруженный час.
