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。请修正密钥并等待封禁结束后再重试。速率限制响应头
只要密钥通过验证,每个响应都会带有四个头部,描述该请求所消耗的额度: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 中同时做到这两点的一个简单循环:
轮询与流
挂单流 会在挂单进入目录后约 0.3 秒发布new 事件。2026 年 10 月 26 日的实测:中位数 0.34 秒,最大值不到 0.5 秒。无论以多快的频率轮询 GET /v1/listings,都不可能比流更早看到一个挂单。所有密钥在同一时刻收到同一个流——不存在优先级。
- 获取新挂单和
gone事件时,请保持一个流连接。使用Last-Event-ID重连,或从 挂单快照 的X-Stream-Position开始,就不会遗漏任何事件。 - 带筛选条件的读取——某一件物品、某个磨损值区间、某个价格区间——请使用
GET /v1/listings。