Recherche vérifiée par sources: OKX
Le corps de l'article est affiché dans sa version anglaise vérifiée. La traduction sera ajoutée après revue des sources.
Verified Fact Boundary
1. OKX published a WebSocket orders channel push behavior adjustment on July 16, 2026. 2. OKX says affected post-only and RPI order types move “state: live” to after successful book entry, with about a one millisecond delay. 3. OKX says failed post-only order placement caused by crossing the BBO now produces only “state: canceled” rather than “state: live” followed by “state: canceled.” 4. OKX says the affected order types are post_only, mmp_and_post_only and rpi, while regular limit, market, ioc and fok behavior remains unchanged. 5. OKX API documentation says successful request responses can mean acceptance, while users should refer to order WebSocket updates for amendment or cancellation confirmation.
Réduire
Decision Matrix
Tableau de l’article : faites défiler horizontalement ou placez le focus sur le tableau et utilisez les flèches.
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Acknowledgement | the exchange has received or accepted an order message | separate transport acknowledgement from final order state | gateway latency and private matching details |
| Final state | the last usable order state after validation, book entry, fill or cancellation | wait for the explicit state update before reconciling | private account event timing |
| Post-only exception | an order type that can cancel when it would cross the book | treat live-then-canceled sequences as a special case | future matching-engine rules |
| Amend result | the source field that explains a successful or failed amendment | record amend result and source before retrying | venue-specific reject reason depth |
| Cancel result | confirmation that an order is canceled rather than merely requested | wait for canceled state before reusing exposure | network or session failure timing |
| Rate-limit mode | how requests behave when order-rate limits are hit | design retry budgets around documented limits | private account tier or subaccount limits |
| WebSocket channel | the feed that carries order-state updates | subscribe and reconcile before trusting UI-only state | connection drop handling |
| REST fallback | the secondary route for order checks or repair | use only with idempotent identifiers and logs | venue incident behavior |
| Evidence packet | non-secret request id, order id, timestamp and official URL | store operational evidence without API secrets | sensitive account values |
| Stop rule | when the article cannot support action | stop if accepted, live, filled and canceled states are conflated | future API changes |
Source Map
- OKX Europe: OKX WebSocket Orders Channel Push Behavior Adjustment Announcement (okx-websocket-orders)
- OKX Technical Support: OKX API guide (okx-api-guide)
- OKX United States: OKX API Agreement (okx-api-agreement)
- OKX Help Center: API Announcements (okx-api-announcements)
Control Notes
1. Acknowledgement
Acknowledgement is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means the exchange has received or accepted an order message. The practical action is to separate transport acknowledgement from final order state. The unresolved edge is gateway latency and private matching details, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, acknowledgement should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material. The record can stay simple: official source URL, access date, product or network under review, and a non-secret note describing why the next step is acceptable. Evidence must avoid balances, identity documents, API keys, recovery phrases, private keys, passphrases, verification codes and support-ticket private data.
2. Final state
Final state is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means the last usable order state after validation, book entry, fill or cancellation. The practical action is to wait for the explicit state update before reconciling. The unresolved edge is private account event timing, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, final state should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
Vérifiez l’éligibilité régionale et les conditions du compte
Ouvrir →3. Post-only exception
Post-only exception is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means an order type that can cancel when it would cross the book. The practical action is to treat live-then-canceled sequences as a special case. The unresolved edge is future matching-engine rules, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, post-only exception should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
4. Amend result
Amend result is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means the source field that explains a successful or failed amendment. The practical action is to record amend result and source before retrying. The unresolved edge is venue-specific reject reason depth, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, amend result should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
5. Cancel result
Cancel result is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means confirmation that an order is canceled rather than merely requested. The practical action is to wait for canceled state before reusing exposure. The unresolved edge is network or session failure timing, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, cancel result should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
6. Rate-limit mode
Rate-limit mode is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means how requests behave when order-rate limits are hit. The practical action is to design retry budgets around documented limits. The unresolved edge is private account tier or subaccount limits, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, rate-limit mode should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
7. WebSocket channel
WebSocket channel is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means the feed that carries order-state updates. The practical action is to subscribe and reconcile before trusting UI-only state. The unresolved edge is connection drop handling, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, websocket channel should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
8. REST fallback
REST fallback is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means the secondary route for order checks or repair. The practical action is to use only with idempotent identifiers and logs. The unresolved edge is venue incident behavior, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
For an operator, rest fallback should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
9. Evidence packet
Evidence packet is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means non-secret request id, order id, timestamp and official URL. The practical action is to store operational evidence without API secrets. The unresolved edge is sensitive account values, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
10. Stop rule
Stop rule is the part of the decision where the reader must turn public evidence into an operating rule. In this article, it means when the article cannot support action. The practical action is to stop if accepted, live, filled and canceled states are conflated. The unresolved edge is future API changes, so this package does not convert uncertainty into a promise, ranking, reward, approval, safety claim, future availability claim or invitation to deposit.
Practical Takeaway
The safest version of this article is boring and exact. OKX changed the practical meaning of a WebSocket order-state signal for post-only and RPI workflows. Its July 16, 2026 announcement says the “state: live” event for affected orders is pushed only after the order has successfully entered the book, with about a one millisecond delay, and failed post-only or RPI placement scenarios now push only “state: canceled” instead of “state: live” followed by “state: canceled.” The useful decision is not that OKX orders are risk-free; it is that API users must separate request acknowledgement, book-entry confirmation, amendment result, cancellation result and final reconciliation before retrying or reporting exposure. The user outcome is a clearer next inspection step, not a promise that a platform, API, transfer route or tokenized asset will work under every future condition.
Thèmes et outils:API des plateformes et données de marché
Vérifiez l’éligibilité régionale et les conditions du compte
Ouvrir →Sources
04- OKX WebSocket Orders Channel Push Behavior Adjustment Announcement · okx.com
- OKX API guide · okx.com
- OKX API Agreement · okx.com
- API Announcements · okx.com