OKX expTime 与速率限制准备清单
本文正文暫以英文原文展示，翻譯版本需完成來源複核後再發布。
已验证事实边界
1. OKX documentation describes transaction timeouts and says expTime can be used as a request effective deadline for supported order and amend requests. 2. OKX documentation says a request rejected due to rate limits returns error code 50011. 3. OKX documentation says public unauthenticated REST rate limits are based on IP address. 4. OKX documentation says private REST and WebSocket order-management rate limits are based on User ID, with sub-accounts having individual User IDs. 5. OKX API Agreement points users to the OKX API documentation for endpoints, rate limits, authentication requirements and data schemas. 6. A venue update does not prove a private account has access to the endpoint, rate tier, product, region or sub-account mode.
收起完整分析
决策矩阵
文章表格：可橫向滑動，或聚焦表格區域後使用方向鍵。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Effective deadline | expTime narrows how long a supported order request can remain actionable | set a short deadline for latency-sensitive order automation and log rejected deadlines | whether every client wrapper passes the header exactly as intended |
| Endpoint scope | only supported order and amend endpoints should be treated as expTime-enabled | map each mutating endpoint before assuming timeout behavior | whether batch and single order calls share the same failure semantics |
| Rate-limit owner | private order limits are tied to User ID rather than only IP | separate sub-account identity, parent account identity and API key in logs | whether shared automation workers accidentally consume the same user limit |
| Error classification | 50011 represents rate-limit rejection in the documented guide | classify it separately from authentication, instrument, balance or order-rule errors | whether a retry would breach the next window again |
| Acknowledgement vs final state | a request accepted before expTime still needs order-state reconciliation | query order status after every timeout or network disconnect | whether a lost response created a live order |
| Private availability | documentation can describe an endpoint before a user account can use it | verify region, product, mode and account tier in a non-secret test | whether product access is login, entity or jurisdiction dependent |
来源地图
- OKX Technical Documentation：OKX API guide（okx-api-guide）
- OKX Help Center：OKX API Agreement（okx-api-agreement）
- NexuAlpha Official Source Registry：Official source registry policy for venue evidence（nexualpha-source-registry）
控制说明
1. Effective deadline
这一项要求读者把公开来源翻译成操作规则。这里的含义是：expTime narrows how long a supported order request can remain actionable。可执行动作是：set a short deadline for latency-sensitive order automation and log rejected deadlines。仍然未知的是：whether every client wrapper passes the header exactly as intended。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、安全保证、恢复保证、平台排名或价格暗示。
2. Endpoint scope
这里的含义是：only supported order and amend endpoints should be treated as expTime-enabled。可执行动作是：map each mutating endpoint before assuming timeout behavior。仍然未知的是：whether batch and single order calls share the same failure semantics。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
3. Rate-limit owner
这里的含义是：private order limits are tied to User ID rather than only IP。可执行动作是：separate sub-account identity, parent account identity and API key in logs。仍然未知的是：whether shared automation workers accidentally consume the same user limit。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
4. Error classification
这里的含义是：50011 represents rate-limit rejection in the documented guide。可执行动作是：classify it separately from authentication, instrument, balance or order-rule errors。仍然未知的是：whether a retry would breach the next window again。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
5. Acknowledgement vs final state
这里的含义是：a request accepted before expTime still needs order-state reconciliation。可执行动作是：query order status after every timeout or network disconnect。仍然未知的是：whether a lost response created a live order。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
6. Private availability
这里的含义是：documentation can describe an endpoint before a user account can use it。可执行动作是：verify region, product, mode and account tier in a non-secret test。仍然未知的是：whether product access is login, entity or jurisdiction dependent。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
仍需明确的未知项
- whether every client wrapper passes the header exactly as intended
- whether batch and single order calls share the same failure semantics
- whether shared automation workers accidentally consume the same user limit
- whether a retry would breach the next window again
- whether a lost response created a live order
- whether product access is login, entity or jurisdiction dependent
实用结论
OKX API 文档把订单超时处理变成了明确的请求控制决策。当前 API guide 描述了用于 place-order 与 amend-order calls 的可选 expTime request header，使请求在指定 effective deadline 后可以被丢弃；同时文档描述 rate limits，其中 private REST 与 WebSocket order-management limits 绑定 User ID，被速率限制拒绝时返回 error code 50011。安全准备结果是：在依赖 OKX 订单自动化前，先测试 expTime、endpoint-level limits、sub-account identity、retry behavior、order acknowledgement 与 final state。 本文停在证据边界内，帮助读者决定下一步核验什么，而不是把公开文档改写成私人账户、钱包、API key、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。
相關專題與工具:交易所 API 與行情資料核查
來源與證據
02- OKX API guide · okx.com
- OKX API Agreement · okx.com