Skip to main content
API CSBoard применяет лимиты запросов на каждый ключ, чтобы сохранять стабильность сервиса для всех пользователей. Если вы превышаете лимит, то сразу получаете ответ 429 — ни один запрос не обрабатывается частично. Реализуйте клиент так, чтобы он считывал заголовок Retry-After и делал паузу перед повтором, а не долбил эндпоинт в плотном цикле.

Лимиты по эндпоинтам

Лимиты считаются на API-ключ в фиксированных минутных окнах: счётчик обнуляется в начале каждой минуты. Единственное исключение — фид цен без ключа: его лимит считается по IP-адресу.
30 запросов с неверными или отсутствующими API-ключами с одного IP-адреса в течение минуты автоматически включают 5-минутный бан на уровне IP. Во время бана каждый запрос с этого IP получает 429 too_many_failed_auth, какой бы ключ он ни содержал. Исправьте ключ и дождитесь окончания бана, прежде чем повторять запросы.
Самый дешёвый способ укладываться в лимиты — перестать опрашивать то, что мы можем присылать сами. Вебхуки доставляют состояние ордера по мере изменений, а SSE-стрим листингов присылает события new и gone по одному соединению — ни то ни другое не расходует бюджет запросов на каждое событие.

Формат ответа 429

При превышении лимита на ключ API возвращает:
Значение заголовка Retry-After — целое число секунд. Для лимитов на ключ это 60: такой паузы всегда достаточно, потому что счётчик обнуляется в начале следующей минуты. Эндпоинт массового снапшота использует отдельный код ошибки при превышении лимита:
GET /v1/public/prices без ключа ограничивается по IP-адресу, а не по ключу, и в теле его ответа 429 нет поля code — ориентируйтесь на статус и Retry-After:

Обработка 429 в клиенте

Считывайте Retry-After и спите как минимум столько секунд, прежде чем повторять запрос. Ниже показан простой цикл повторов на bash:
Добавьте небольшое случайное смещение (например, sleep $((RETRY_AFTER + RANDOM % 5))) при запуске нескольких воркеров параллельно, чтобы они не возобновляли работу одновременно и не срабатывали по лимиту снова.

Повышение лимитов

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