Skip to main content
PUT
Replace existing order

Authorizations

X-Monaco-Signature
string
header
required

Ed25519 session-key request signing. Every authenticated request carries three headers: X-Monaco-PublicKey (64-char lowercase-hex session public key), X-Monaco-Timestamp (Unix milliseconds, within 30s of server time), and X-Monaco-Signature (hex ed25519 signature). The signature is over METHOD\npath?query\ntimestamp_ms\nSHA256_hex(body), where the body hash is the SHA-256 of the empty byte string when there is no body. Obtain the session keypair from POST /api/v1/auth/challenge followed by POST /api/v1/auth/verify.

Path Parameters

orderId
string
default:2b1a5f9c-0000-4000-8000-000000000003
required

Body

application/json
selfTradePreventionMode
enum<string> | null

Per-order self-trade-prevention override for the replacement: CANCEL_MAKER, CANCEL_TAKER, CANCEL_BOTH, or SKIP (see the create-order field for the full semantics). A replacement is a new order with a new id, so it carries its own value and inherits nothing from the original — restate it to keep the override. Omitted, your wallet's configured default applies, else the platform default CANCEL_MAKER. The requested value is echoed back as selfTradePreventionMode on order reads, absent when omitted here.

Available options:
CANCEL_MAKER,
CANCEL_TAKER,
CANCEL_BOTH,
SKIP
Example:

"CANCEL_TAKER"

price
string | null

New limit price (if changing)

Example:

"35500.00"

quantity
string | null

New TOTAL quantity (if changing). On a partially filled order the replacement rests total minus filled, and collateral is locked for that remainder only (FIX cancel/replace convention: LeavesQty = OrderQty - CumQty). Must exceed the filled amount. Omitted, the replacement keeps the unfilled remainder. Margin reduce-only orders are the exception: their quantity is a close size measured against the live position, placed as given, with no subtraction and no must-exceed-filled rule.

Example:

"0.7"

useMasterBalance
boolean | null

Use master account balance for sub-account orders

Example:

false

postOnly
boolean | null

Post-only: reject instead of matching if this limit order would cross the book — rejected with HTTP 400 / gRPC INVALID_ARGUMENT carrying the structured error code POST_ONLY_WOULD_CROSS (REST error-envelope 'code' field; gRPC google.rpc.ErrorInfo reason; batch per-item error.code). Matching the 'post-only order would cross' message substring is a legacy fallback. LIMIT orders with GTC only; rejected on MARKET orders and IOC/FOK.

Example:

false

clientOrderId
string | null

Client-assigned correlation handle, echoed back on order reads (detail and list) and on order WebSocket events. At most 64 characters from [A-Za-z0-9._:-]; surrounding whitespace is trimmed before storage, and a blank or whitespace-only value is treated as absent. Uniqueness is enforced only among your orders that are RESTING on the book: a create or replace reusing a value another of your resting orders still holds is rejected with HTTP 409 / gRPC ALREADY_EXISTS and the code CLIENT_ORDER_ID_CONFLICT. An order that never rests — MARKET, IOC/FOK, or a LIMIT that fills completely on arrival — does not take the handle, and the value is released the moment any order reaches a terminal state. It is therefore NOT an idempotency key, though on this replace path a retry cannot double-execute: the request names the original order id, and the sequencer revalidates that original in memory and on the book at sequence time, so once the first replacement succeeds the original is gone and a retry is rejected with ORDER_NOT_FOUND rather than placing a second order. That code is itself ambiguous — the original may instead have filled or been cancelled — so the risk here is acting on a stale view, not duplicate execution. Reconcile a lost response against the order WebSocket stream, which carries this value on the submit acknowledgement and on fills, including for orders that never rest; order history is replica-backed and can omit an order that did land. The stream is not replayable and has no sequence number to backfill from, and its fan-out is non-persistent Core NATS: the service can re-establish an ended upstream subscription without closing your socket, so events can be missed while your connection still looks healthy. A matching event is therefore positive proof the order was accepted, but silence is NEVER evidence it was not, and no client-observable condition makes it so. Absent positive evidence the outcome is unresolved: hold and escalate rather than resubmitting. A replacement carries no order type or time-in-force and its original must still be RESTING, so the post-acceptance rejection shapes are unreachable here: the reachable failures are all pre-acceptance — malformed, post-only would cross, handle conflict, or the original no longer resting (ORDER_NOT_FOUND) — and each fails the request, emits no event and is never written to order history (an order rejected AFTER acceptance is persisted with status REJECTED, so only the pre-acceptance class is absent). Where no surface is conclusive, do not resubmit. A replacement is a new order with a new id, so it carries its own value and inherits nothing from the original — restate it to keep the handle.

Example:

"quote-btc-1130-a"

Response

OK

orderId
string<uuid> | null

New replacement order UUID

Example:

"987e6543-e21b-12d3-a456-426614174000"

status
string | null

Result status: SUCCESS or FAILED

Example:

"SUCCESS"

message
string | null

Human-readable status message

Example:

"Order replaced successfully"

originalOrderId
string<uuid> | null

UUID of the original cancelled order

Example:

"123e4567-e89b-12d3-a456-426614174000"

updatedFields
object
matchResult
object