OKX expTime 与速率限制准备清单

决策矩阵

来源地图

• 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、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。