本页为简体中文译文。如有歧义，请以英文原文为准。 阅读英文版 →
跳转到主要内容

速率限制

针对订单操作和 API 请求的按钱包速率限制。

概述​

速率限制采用固定的 60 秒窗口。钱包限制取决于钱包所属的等级，适用于：

  • 下单（POST /order、PUT /order、WebSocket PlaceOrder 以及经 TEE 路由的永续合约订单提交）
  • 撤单（DELETE /order、DELETE /order_cloid 以及经 TEE 路由的永续合约撤单）
  • API 请求（钱包范围的读取请求及其他签名写入请求）

撤单、代理授权、MMP 写入和公共风险模拟另有按网络来源计算的独立限制，并设有进程级上限。

计数器由每个 API 进程保存在内存中，不在副本之间共享。因此，请将公布的数值视为单个进程所能接受的最大值，而非整个集群的总额度。

默认限制​

等级下单/分钟撤单/分钟API 请求/分钟最大挂单数最大持仓数
默认6012060010050
等级 130603005020
等级 21203001,200500200
做市商1,2002,4006,0005,000无限制

新钱包默认获得默认限制。如需升级等级，请联系支持团队。您当前的 API 请求限制可在任何钱包范围读取请求的 X-RateLimit-Limit 响应头中查看，例如 GET /orders?wallet=...。

速率限制响应​

超出速率限制时，API 返回 429 Too Many Requests：

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded for OrderPlacement: 60 per minute, retry after 45 seconds",
  "retry_after_secs": 45,
  "limit": 60
}

响应头​

受钱包限制的端点会返回以下响应头。429 响应包含 X-RateLimit-Limit、X-RateLimit-Remaining: 0 和 Retry-After，但不包含 X-RateLimit-Reset：

响应头说明示例
X-RateLimit-Limit每个窗口允许的最大请求数60
X-RateLimit-Remaining当前窗口剩余的请求数42
X-RateLimit-Reset窗口重置时的 Unix 时间戳（秒，仅成功响应包含）1737312060
Retry-After距可重试的秒数（仅 429 响应包含）45

响应头示例​

成功请求：

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1737312060

被限流的请求：

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

速率限制类别​

每种操作类型的速率限制分别计算：

下单​

按钱包计入所属等级的下单/分钟额度：

  • POST /order 和 PUT /order
  • WebSocket PlaceOrder
  • POST /v1/tee-perp/orders/submit 及其他永续合约订单提交，计入账户管理者钱包

POST /bulk_order 和 PUT /bulk_order 每个请求最多包含 50 个条目。

撤单​

按钱包计入所属等级的撤单/分钟额度：

  • DELETE /order 和 DELETE /order_cloid
  • 永续合约撤单，计入签名的 API 钱包

所有撤单路由（包括 DELETE /bulk_order 和 DELETE /bulk_order_cloid）在签名验证之前还受到额外限制：每个网络来源每分钟 6,000 个撤单腿，进程级每分钟 60,000 个撤单腿。批量撤单中每个条目计为一个撤单腿。

API 请求​

按钱包计入所属等级的 API 请求/分钟额度：

  • 钱包范围的读取请求，以 wallet 查询参数为键
  • 上文未列出的签名写入请求，例如 MMP 配置和保证金模式

RFQ 提交​

POST /rfq/request 和 WebSocket RFQ 提交命令限制为每个钱包每分钟 10 次，与等级无关。

风险模拟​

公共投资组合和订单模拟（POST /risk/simulate/portfolio、 POST /risk/simulate/orders 以及永续合约预览 POST /v1/tee-perp/preview） 另有独立限制：每个网络来源每分钟 60 次请求，进程级每分钟 600 次请求。单个 API 进程中最多同时运行四个模拟。超出配额或遇到模拟工作线程已饱和的请求将返回 429 Too Many Requests。

代理授权​

POST /approve-agent、DELETE /revoke-agent 和 DELETE /revoke-all-agents 在签名验证之前受到限制：每个网络来源每分钟 120 次请求，进程级每分钟 1,200 次请求。

MMP 写入​

MMP 配置写入在签名验证之前受到限制：每个网络来源每分钟 120 次请求，进程级每分钟 1,200 次请求。此限制叠加于钱包的 API 请求限制之上。

持仓与订单限制​

除速率限制外，钱包还有最大挂单数和最大持仓数限制：

限制类型说明拒绝方式
最大挂单数同时存在的挂单上限钱包达到上限时，新订单将被拒绝
最大持仓数不同持仓的上限（-1 = 无限制）若订单会开立新持仓，则被拒绝

这些属于订单拒绝，而非 HTTP 错误。订单响应为 HTTP 200，带有 status: "REJECTED" 和 reason，例如：

max_open_orders_exceeded: current=100, limit=100
max_positions_exceeded: wallet 0x... has 50 positions, limit is 50

最佳实践​

处理速率限制​

  1. 监控响应头：主动跟踪 X-RateLimit-Remaining
  2. 遵守 Retry-After：重试前等待指定的时长
  3. 实现退避：对连续的 429 响应使用指数退避
import time

def place_order_with_retry(order, max_retries=3):
    for attempt in range(max_retries):
        response = api.place_order(order)

        if response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 60))
            time.sleep(retry_after)
            continue

        return response

    raise RateLimitError("Max retries exceeded")

优化请求用量​

  1. 使用批量端点：通过 POST /bulk_order 在一个请求中提交多个订单
  2. 批量撤单：使用 DELETE /bulk_order 或 DELETE /bulk_order_cloid，而非多次发送 DELETE /order 请求
  3. 使用 WebSocket 获取更新：订阅订单更新，而非轮询 GET /orders

监控​

在客户端跟踪以下指标：

  • 各操作类型的请求速率
  • X-RateLimit-Remaining 的变化趋势
  • 429 响应的频率
  • Retry-After 的平均时长

错误参考​

HTTP 状态码错误代码说明
429rate_limit_exceeded超出速率限制，请在指定时间后重试

完整错误参考请参阅错误。

最后更新于