源头核验研究

加密交易所 API 错误、幂等性与重试窗口披露雷达

4 分钟

已验证事实边界

1. Coinbase Exchange order documentation exposes client order identity surfaces useful for cancel and reconciliation workflows. 2. OKX API documentation describes request-deadline and rate-limit behavior in its technical guide. 3. Kraken WebSocket v2 order documentation is a source for order-entry request behavior on Kraken's WebSocket API. 4. Binance Spot REST documentation describes signed request timing and request-security concepts. 5. Binance account endpoints provide account and order-state evidence surfaces separate from the initial mutating request. 6. A retry radar should separate idempotency, freshness, rate limits, acknowledgement and final state instead of treating a timeout as permission to repeat.

收起完整分析

决策矩阵

文章表格:可横向滑动,或聚焦表格区域后使用方向键。

CheckWhat it meansPractical actionUnknown to keep explicit
Idempotency keyclient order identifiers reduce ambiguity only if they survive retriespreserve non-secret client ids across retry boundarieswhether a wrapper regenerates ids after process restart
Freshness windowtimestamp and deadline controls can make a queued request staledrop stale mutating requests rather than replaying them blindlywhether queue delay is measured before network dispatch
Rate-limit ownerrate-limit errors may belong to user, endpoint or connection scopetrack owner separately before retry backoffwhether another strategy consumed the same limit
Acknowledgement gapa timeout does not prove the venue ignored the orderquery final state before sending a replacement requestwhether delayed acknowledgement arrives after local retry
State reconciliationaccount or order endpoints are separate evidence surfaces from mutating endpointsrequire final status evidence before closing the incidentwhether partial fills changed the intended exposure
Log minimizationretry incidents are tempting places to dump full payloadslog ids, endpoint, source URL, status and stop condition onlywhether logs expose balances, keys or strategy logic

来源地图

  • Coinbase Developer Documentation:Cancel an order(coinbase-cancel-order)
  • OKX Technical Documentation:OKX API guide(okx-api-guide)
  • Kraken API Documentation:add_order WebSocket v2(kraken-ws-add-order)
  • Binance Developer Documentation:General REST API Information(binance-spot-rest)
  • Binance Developer Documentation:Account Endpoints(binance-account-endpoints)

控制说明

1. Idempotency key

这一项要求读者把公开来源翻译成操作规则。这里的含义是:client order identifiers reduce ambiguity only if they survive retries。可执行动作是:preserve non-secret client ids across retry boundaries。仍然未知的是:whether a wrapper regenerates ids after process restart。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、安全保证、恢复保证、平台排名或价格暗示。

2. Freshness window

这里的含义是:timestamp and deadline controls can make a queued request stale。可执行动作是:drop stale mutating requests rather than replaying them blindly。仍然未知的是:whether queue delay is measured before network dispatch。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

3. Rate-limit owner

这里的含义是:rate-limit errors may belong to user, endpoint or connection scope。可执行动作是:track owner separately before retry backoff。仍然未知的是:whether another strategy consumed the same limit。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

4. Acknowledgement gap

这里的含义是:a timeout does not prove the venue ignored the order。可执行动作是:query final state before sending a replacement request。仍然未知的是:whether delayed acknowledgement arrives after local retry。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

5. State reconciliation

这里的含义是:account or order endpoints are separate evidence surfaces from mutating endpoints。可执行动作是:require final status evidence before closing the incident。仍然未知的是:whether partial fills changed the intended exposure。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

6. Log minimization

这里的含义是:retry incidents are tempting places to dump full payloads。可执行动作是:log ids, endpoint, source URL, status and stop condition only。仍然未知的是:whether logs expose balances, keys or strategy logic。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

仍需明确的未知项

  • whether a wrapper regenerates ids after process restart
  • whether queue delay is measured before network dispatch
  • whether another strategy consumed the same limit
  • whether delayed acknowledgement arrives after local retry
  • whether partial fills changed the intended exposure
  • whether logs expose balances, keys or strategy logic

实用结论

本轮雷达发现是:交易所 API 文档通常把重试安全的不同片段分散在多个位置,而不是作为一个完整控制项呈现。Coinbase 记录 client order identifiers 与认证订单端点;OKX 记录 request deadlines 与 rate-limit errors;Kraken 记录 authenticated WebSocket tokens 与订单端点;Binance 记录 signed request timing 与订单控制。实用结论是:任何自动化重试可变更订单动作前,应先建立区分 idempotency key、request freshness、rate-limit owner、acknowledgement、final state 与 audit log 的运行手册。 本文停在证据边界内,帮助读者决定下一步核验什么,而不是把公开文档改写成私人账户、钱包、API key、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。

来源与证据

05
  1. Coinbase Developer DocumentationCancel an order
  2. OKX Technical DocumentationOKX API guide · okx.com
  3. Kraken API Documentationadd_order WebSocket v2 · docs.kraken.com
  4. Binance Developer DocumentationGeneral REST API Information · developers.binance.com
  5. Binance Developer DocumentationAccount Endpoints · developers.binance.com