/orders API is distinct from generic conditional intents. Use the matching SDK controller and supported venue configuration. Do not use the readiness of one service as the readiness of the other.
Endpoints
/orders/status returns endpoint-specific readiness rather than a fill guarantee. A false placement flag can coexist with working reads and recovery. Preserve history and cancellation access when new placements are unavailable.
Signed revisions
Returned orders exposeorderId, revisionId and revision. Keep stable order identity separate from the signature and exact revision being amended or cancelled. Editing amount, limit, timing or other signed terms requires a fresh accepted preview and signature.
A replacement is a new immutable signed revision. The API arbitrates replacement, cancellation and execution ownership. An execution already claimed by the worker can prevent an amendment or cancellation; handle 409 by reading the current order rather than claiming success or submitting a duplicate.
Registration returns 201 when accepted. Acceptance does not mean the order filled. Read its status, transaction evidence and settlement result through the matching order controller. Execution belongs to the managed-order worker, so manual action-step execution is rejected.
For a new trigger-based integration, start with the conditional intent guide and its configured evaluator instead of constructing a venue-specific managed-order payload by hand.