Managing Submissions

updateOrderSubmission amends a live submission in place; cancelOrderSubmission and bulkCancelOrderSubmissions take it off the book.

What you can do, by status

Status	Amend	Cancel
QUEUED	No	Yes — pulled before it ever rests
RESTING	Yes	Yes
EXECUTING	No	No — a mid-flight match must finish or fail
PARTIALLY_FILLED	Yes	Yes
SETTLING	No — nothing on the book	No — nothing on the book
FILLED / CANCELLED / EXPIRED	No	No

Amend and cancel act on what is resting. Units already matched are untouched either way: an amend reprices the resting remainder, and a cancel pulls it. A cancel on an order with fills in flight leaves it SETTLING — the response carries that status — and it lands CANCELLED with its settledQuantity once those fills deliver.

Amending

updateOrderSubmission takes submissionId plus any of: qty, allInPrice, minOrderSize, minValueCents, expiresAt, the buy-side fulfilment intents (autoOuttake, shouldVault, paymentRail, paymentTokenId, recipientAddressId), and originAddressId.

Not amendable: targeting (assetConfigurationIds, keyIds, marketIds), direction, orderType, timeInForce, slippage, externalReferenceId. A SELL's qty is also fixed — its units are reserved to the ask. Strategy-managed submissions and priority orders can't be amended at all. For any of these, cancel and recreate.

mutation {
  updateOrderSubmission(input: {
    submissionId: "f7c8f0ea-9bf2-4b1f-8aec-02158eb08e66"
    qty: 2
    allInPrice: 450
  }) {
    submission { id status qty allInPrice updatedAt }
    error { message code }
  }
}

{
  "updateOrderSubmission": {
    "submission": {
      "id": "f7c8f0ea-9bf2-4b1f-8aec-02158eb08e66",
      "status": "RESTING",
      "qty": 2,
      "allInPrice": 450,
      "updatedAt": "2026-08-11T19:16:24.389089Z"
    },
    "error": null
  }
}

Amending keeps queue position

An amend updates the submission's one resting order in place — same id, same time priority. A reprice that now meets the other side of the book crosses immediately and the fills come back as usual. Reading the child with includeChildBidOrAsk before and after shows the same id at the new price.

Amend validation

Code	Trigger
ORDER_SUBMISSION_NOT_FOUND	Unknown id, or a submission that isn't yours
INVALID_STATUS_TRANSITION	Submission isn't in an amendable status
FIELD_NOT_AMENDABLE	qty on a SELL
PRIORITY_SUBMISSION_NOT_AMENDABLE / SIGMAFILL_MANAGED	Priority order or strategy-managed submission
INVALID_QTY	qty not greater than zero, or not above what has already filled
INVALID_PRICE	allInPrice not greater than zero
INVALID_MIN_ORDER_SIZE	minOrderSize would exceed the effective qty
INVALID_EXPIRES_AT	In the past, or set on a DAY order
INVALID_ADDRESS	recipientAddressId / originAddressId is not one of your saved addresses
VAULT_ADDRESS_CONFLICT	Post-amend state has both shouldVault and a recipientAddressId — checked against the merged result, so amending only one field can still land on the conflicting pair
RECIPIENT_ADDRESS_REQUIRED	The amend would clear the destination a taker-shipping acknowledgment was quoted against

An all-or-none submission (minOrderSize equal to qty) stays all-or-none through a qty amend: the minimum re-clamps to the new quantity unless you explicitly set a new one.

Cancelling one submission

mutation {
  cancelOrderSubmission(input: { submissionId: "f7c8f0ea-9bf2-4b1f-8aec-02158eb08e66" }) {
    submission { id status }
    error { message code }
  }
}

{ "submission": { "id": "f7c8f0ea-9bf2-4b1f-8aec-02158eb08e66", "status": "CANCELLED" }, "error": null }

Cancelling the submission cancels everything it rested on the book, atomically — a failure rolls the whole cancel back rather than leaving live fillable orders behind.

Code	Trigger
ORDER_SUBMISSION_NOT_FOUND	Unknown id, or a submission that isn't yours
ALREADY_FILLED	Submission already fully filled
ALREADY_CANCELLED	Submission already cancelled or expired
NOTHING_RESTING	SETTLING — every unit is matched and moving, nothing left on the book to pull
INVALID_STATUS_TRANSITION	EXECUTING — a mid-flight match must finish or fail

Cancelling in bulk

bulkCancelOrderSubmissions addresses submissions three ways, and the conditions compose — every condition you pass must match:

Field	Scope
submissionIds	Explicit submission ids
externalReferenceIds	Your own reference ids
direction	Only BUY or only SELL
marketIds / assetIds / assetConfigurationIds	Submissions targeting these products
externalIdentifiers	Submissions targeting the configurations these ids resolve to. An unresolvable id returns UNRESOLVED_EXTERNAL_IDENTIFIERS and cancels nothing, rather than widening the cancel

mutation {
  bulkCancelOrderSubmissions(input: {
    direction: BUY
    assetConfigurationIds: ["315bc6db-3f16-49ec-b649-8be3b8753fb7"]
  }) {
    submissions { id externalReferenceId status }
    error { message }
  }
}

The payload returns only the submissions that actually transitioned to CANCELLED. Already-terminal or non-cancellable submissions are skipped silently, not errored — bulk cancel is idempotent by design, safe to retry. Running the same call twice returns an empty list the second time.

Two behaviors to internalize before wiring this into risk controls:

No filters means everything

An empty input cancels every cancellable submission on the account. That is the intended panic button — pull all quotes now — but make sure invoking it with no scope is a decision, not a default.

Unconstrained dimensions always match

A product filter matches submissions that either overlap it or don't constrain that dimension at all. A submission created without marketIds has no market targeting, so any marketIds cancel sweeps it too.

Repricing at scale

There is no bulk amend. Repricing many orders is cancel-replace — bulkCancelOrderSubmissions scoped by externalReferenceIds, then bulkCreateOrderSubmissions with the new prices. Give every order an externalReferenceId up front so the cancel side can be addressed precisely and never has to fall back to a product-scoped sweep.