> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trdrs.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage working orders

> Move a resting order's price, cancel one, or sweep the book — and read the outcome honestly.

Everything on this page keys off one value: the broker order id. Once you hold it you can move an
order, cancel it, or find it again after a reconnect.

## Where a broker order id comes from

`brokerOrderId` is the venue's own id for one order. Three places hand it to you, and they agree:

| Source                                                                  | When you get it                                                  |
| ----------------------------------------------------------------------- | ---------------------------------------------------------------- |
| [Place an order](/api-reference/trading/place-an-order)                 | In the response, the moment the order lands.                     |
| [List orders](/api-reference/account/list-orders)                       | On demand. Omit `filter` and you get the working orders.         |
| [Stream account updates](/api-reference/account/stream-account-updates) | On every frame, in the `orders` array, at that frame's revision. |

It is the venue's id, not ours, and a composite re-place can mint a new one — so read it back from
the response rather than assuming it survived.

<Steps>
  <Step title="Move a resting order to a new price">
    [Replace an order](/api-reference/trading/replace-an-order) is one operation under one
    idempotency key. `orderType` must match the type the engine reports for that order, or the call
    is refused with `400 order_type_mismatch`.

    ```bash theme={null}
    curl -X POST "$TRDRS_API_BASE_URL/api/trading/replace" \
      -H "Authorization: Bearer $TRDRS_TENANT_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "brokerOrderId": "234992187",
        "instrument": "ESU6",
        "side": "sell",
        "qty": 2,
        "orderType": "limit",
        "price": 6497.25,
        "clientOrderId": "replace-tp-1787582100"
      }'
    ```

    `price` is a limit's resting price, a stop's trigger, and a `stop_limit`'s trigger. A
    `stop_limit` also needs `stopLimitPrice` — the limit its trigger converts to.
  </Step>

  <Step title="Read the outcome, not the status code">
    The engine amends natively where the venue truly amends, keeping the order's identity, and runs
    a typed composite everywhere else. A `200` therefore does not mean the move worked. `outcome`
    is the truth to surface:

    | `outcome`                  | Read it as                                                                 |
    | -------------------------- | -------------------------------------------------------------------------- |
    | `amended`                  | Success. The venue amended the order in place.                             |
    | `replaced`                 | Success. A composite re-place landed; `brokerOrderId` is the surviving id. |
    | `restored`                 | Not a success. The re-place was rejected and the original was put back.    |
    | `restored_without_bracket` | Not a success. The entry was restored without its exits.                   |
    | `gone`                     | Not a success. There was no longer an order to move.                       |
    | `order_lost`               | Not a success. Re-sync from the account stream before doing anything else. |
    | `unconfirmed`              | The engine cannot yet say. Re-sync from the account stream.                |

    The contract names `amended` and `replaced` as the successes; treat everything else as a state
    to show the trader, not a failure to retry blindly.
  </Step>

  <Step title="Carry the exits through the replace">
    Send `restoreBracket` — the order's current exits as you know them — on every replace of an
    entry that has exits attached. Without it, a rejected re-place restores the entry without its
    exits, and that is what `restored_without_bracket` reports.

    ```bash theme={null}
    curl -X POST "$TRDRS_API_BASE_URL/api/trading/replace" \
      -H "Authorization: Bearer $TRDRS_TENANT_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "brokerOrderId": "234992187",
        "instrument": "ESU6",
        "side": "buy",
        "qty": 2,
        "orderType": "limit",
        "price": 6479.25,
        "restoreBracket": {
          "stopLoss": { "price": 6472.5, "offsetTicks": 32 },
          "takeProfit": { "price": 6495, "offsetTicks": 58 }
        },
        "clientOrderId": "replace-entry-1787582260"
      }'
    ```

    The same call can also change the exits: `stopLoss` and `takeProfit` here are end states — an
    object sets the leg, `null` removes it, omitting it leaves it alone.
  </Step>

  <Step title="Cancel one order">
    [Cancel an order](/api-reference/trading/cancel-an-order) takes the broker order id and nothing
    else.

    ```bash theme={null}
    curl -X POST "$TRDRS_API_BASE_URL/api/trading/cancel" \
      -H "Authorization: Bearer $TRDRS_TENANT_KEY" \
      -H "Content-Type: application/json" \
      -d '{ "brokerOrderId": "234992187" }'
    ```

    The engine answers only after the venue accepts the cancel, and the copier mirrors it to
    follower accounts only after that acceptance, so leaders and followers never disagree about
    what rests. Either way, the account stream is the truth of what remains.
  </Step>

  <Step title="Sweep the book">
    [Cancel all working orders](/api-reference/trading/cancel-all-working-orders) cancels every
    working order. Pass `instrument` to scope the sweep to one; omit it to cancel across all
    instruments.

    ```bash theme={null}
    curl -X POST "$TRDRS_API_BASE_URL/api/trading/cancel-all" \
      -H "Authorization: Bearer $TRDRS_TENANT_KEY" \
      -H "Content-Type: application/json" \
      -d '{ "instrument": "ESU6" }'
    ```

    A successful sweep reports the cancelled count. If a venue rejection interrupts it, the answer
    is not a success: it carries `cancel_all_incomplete` plus the number actually cancelled, so you
    re-sync and re-issue rather than believing the book is clear.
  </Step>
</Steps>

## Idempotency across retries

Replacing is a money-path mutation, so it carries `clientOrderId` — one intent, one id, and a
retry of the same intent can never run the move twice. Mint a new id when the trader drags the
order somewhere new; reuse the id when you are retrying the same drag after a timeout.

Cancelling is different. Cancels are idempotent at the venue, so neither cancel route takes an
idempotency key, and a re-issue after a partial failure is safe.

A risk-locked account answers `423` to the replace route. Neither cancel route lists a `423`: the
lock gates new exposure, and a cancel only removes it.

## Where to go deeper

* [Idempotency](/partner-platform/overview/idempotency) — what a claim is and why a retry is safe.
* [Errors](/partner-platform/overview/errors) — the shape of every refusal, and which ones mean stop.
* [Close a position](/guides/close-a-position) — the four ways out, and what each cancels first.
* [Protect a position](/guides/protect-a-position) — the stop and target the replace has to carry.
