跳转到主要内容
CSBoard API 强制执行每密钥的速率限制,以确保服务对所有用户保持稳定。如果您超出限制,会立即收到 429 响应——不会有请求被部分处理。每个响应都会告诉您当前这一分钟还剩多少额度,因此客户端可以在触及限制之前就放慢速度。如果仍然收到 429,请读取 Retry-After 头部并在重试前暂停,而不是在紧密循环中持续冲击端点。

各端点的限制

携带 API 密钥的请求按 每个密钥 以固定的一分钟窗口计数:计数器在每分钟开始时清零。下表中密钥自身的限制是这类请求受到的唯一限制——不会再叠加任何按 IP 的限制。无需密钥的端点 GET /v1/health 和 GET /v1/public/prices 没有密钥可供计数,因此按 IP 地址限流。 GET /v1/key 一次调用即可在 rate_limits 中返回密钥的全部限制。
同一 IP 地址在一分钟内发送 30 个使用 无效或缺失 API 密钥 的请求,将自动触发 5 分钟的 IP 级封禁。封禁期间,来自该 IP 的每个请求无论携带哪个密钥,都会返回 429 too_many_failed_auth。请修正密钥并等待封禁结束后再重试。
保持在限制之内最省力的方法,是不再轮询那些我们可以主动推送的内容。Webhooks 会在订单状态变化时推送,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。 同一密钥的第 4 个并发挂单流会收到 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))),这样它们就不会在同一瞬间全部恢复并立即再次触发限制。

轮询与流

挂单流 会在挂单进入目录后约 0.3 秒发布 new 事件。2026 年 10 月 26 日的实测:中位数 0.34 秒,最大值不到 0.5 秒。无论以多快的频率轮询 GET /v1/listings,都不可能比流更早看到一个挂单。所有密钥在同一时刻收到同一个流——不存在优先级。
  • 获取新挂单和 gone 事件时,请保持一个流连接。使用 Last-Event-ID 重连,或从 挂单快照 的 X-Stream-Position 开始,就不会遗漏任何事件。
  • 带筛选条件的读取——某一件物品、某个磨损值区间、某个价格区间——请使用 GET /v1/listings。

提高您的限制

默认限制适合大多数集成场景,但如果您有高吞吐用例——例如数据管道或高频交易机器人——请 联系我们 讨论为您的账户提高每密钥的限制。