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

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

Запросы с API-ключом считаются на ключ в фиксированных минутных окнах: счётчик обнуляется в начале каждой минуты. Лимиты ключа ниже — единственные, которые действуют на такой запрос: лимита по IP поверх них нет. У эндпоинтов без ключа, GET /v1/health и GET /v1/public/prices, считать по ключу нечего, поэтому их лимит считается по IP-адресу. GET /v1/key возвращает все лимиты ключа одним вызовом — в объекте rate_limits.
30 запросов с неверными или отсутствующими API-ключами с одного IP-адреса в течение минуты автоматически включают 5-минутный бан на уровне IP. Во время бана каждый запрос с этого IP получает 429 too_many_failed_auth, какой бы ключ он ни содержал. Исправьте ключ и дождитесь окончания бана, прежде чем повторять запросы.
Самый дешёвый способ укладываться в лимиты — перестать опрашивать то, что мы можем присылать сами. Вебхуки доставляют состояние ордера по мере изменений, а SSE-стрим листингов присылает события new и gone по одному соединению — ни то ни другое не расходует бюджет запросов на каждое событие.

Заголовки лимитов

Если ключ принят, каждый ответ несёт четыре заголовка о бюджете, который потратил запрос:
Сбавляйте темп по этим заголовкам, а не нащупывайте потолок, упираясь в него. Когда X-RateLimit-Remaining дошёл до 0, придержите запросы этого бюджета на X-RateLimit-Reset секунд.

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

При превышении лимита на ключ API возвращает:
bucket называет исчерпанный бюджет (read, trading или buy_orders), limit_per_min — его потолок. Значение заголовка Retry-After — целое число секунд: сколько осталось до начала нового минутного окна, от 1 до 60. В retry_after_sec то же число. Такой паузы всегда достаточно, потому что счётчик обнуляется вместе с окном. Эндпоинт массового снапшота цен использует отдельный код ошибки при превышении лимита:
Его Retry-After — тоже точный остаток минуты, как и у лимита P2P-записей (rate_limit_exceeded) и лимита котировок Instant Sell (rate_limited). В телах этих ответов только code и detail. Четвёртый одновременный стрим листингов на одном ключе получает 429 too_many_streams с Retry-After: 90. Соединение, оборванное без закрытия, держит свой слот до 90 секунд, поэтому переподключению сразу после сбоя сети, возможно, придётся подождать столько же:
GET /v1/public/prices без ключа ограничивается по IP-адресу, а не по ключу, и в теле его ответа 429 нет поля code — ориентируйтесь на статус и Retry-After:

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

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

Опрос или стрим

Стрим листингов публикует событие new примерно через 0,3 секунды после того, как листинг появился в каталоге. Замер 26 октября 2026 года: медиана 0,34 с, максимум меньше 0,5 с. Как бы часто вы ни опрашивали GET /v1/listings, листинг не появится у вас раньше, чем его доставит стрим. Все ключи получают один и тот же стрим в один и тот же момент — приоритетного уровня нет.
  • Для новых листингов и событий gone держите открытым один стрим. Переподключайтесь с Last-Event-ID или начинайте с X-Stream-Position снапшота листингов — так вы ничего не пропустите.
  • Для выборок с фильтрами — один предмет, диапазон float, ценовой коридор — используйте GET /v1/listings.

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

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