Skip to main content
CSBoard API 强制执行每密钥的速率限制,以确保服务对所有用户保持稳定。如果您超出限制,会立即收到 429 响应——不会有请求被部分处理。请构建您的客户端以检查 Retry-After 头部并在重试前暂停,而不是在紧密循环中持续冲击端点。

各端点的限制

限制按 每个 API 密钥 以固定的一分钟窗口计数:计数器在每分钟开始时清零。唯一的例外是无需密钥的价格数据源,它按 IP 地址限流。
同一 IP 地址在一分钟内发送 30 个使用 无效或缺失 API 密钥 的请求,将自动触发 5 分钟的 IP 级封禁。封禁期间,来自该 IP 的每个请求无论携带哪个密钥,都会返回 429 too_many_failed_auth。请修正密钥并等待封禁结束后再重试。
保持在限制之内最省力的方法,是不再轮询那些我们可以主动推送的内容。Webhooks 会在订单状态变化时推送,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))),这样它们就不会在同一瞬间全部恢复并立即再次触发限制。

提高您的限制

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