> For the complete documentation index, see [llms.txt](https://docs.nexus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexus.xyz/api-reference/account/fetch-order.md).
# GET /orders/{order\_id}
Get order by ID
Get order by ID.
`operationId`: `fetchOrder` · CCXT method: `fetchOrder`
> **Declared server:** `https://api.testnet.nexus.xyz/v1`. See [Networks](/api-reference/guides/networks.md).
**Authentication:** `agentAuth`, `hmacAuth`.
## Get order by ID
> Resolves any order the account placed: resting orders come from the matching engine's authoritative book state, and recently completed orders (filled, cancelled, rejected, expired) are served from the indexer's terminal-order mirror, so an order that fills instantly can still be fetched by the id its placement returned (ENG-10962). The mirror retains the most recent 500 terminal orders per account — the same window \`GET /orders/history\` lists — so anything listable is fetchable. Older terminal orders resolve only through \`GET /orders/history\`.
````json
{"openapi":"3.1.0","info":{"title":"Nexus Exchange API","version":"0.9.101"},"tags":[{"name":"Account","description":"Balance and order management"}],"servers":[{"url":"https://api.testnet.nexus.xyz/v1","description":"Public testnet (play funds) — the default server and /v1 transport base for unversioned paths."},{"url":"https://api.nexus.xyz/v1","description":"Mainnet — **REAL FUNDS**. Collateral is USDX bridged from Ethereum Mainnet; orders placed here move real money, and there is no faucet. The durable per-network base. Listed after testnet on purpose, so nothing that reaches for \"the first https server\" lands on the real-funds target. Not resolvable yet: DNS/TLS is a separate infra change."},{"url":"http://localhost:9090","description":"Local development — the indexer served directly. Not a public network; whatever your local instance holds."}],"security":[{"hmacAuth":[]},{"agentAuth":[]}],"components":{"securitySchemes":{"hmacAuth":{"type":"apiKey","in":"header","name":"X-API-Key","description":"HMAC API key authentication. Send three headers:\n- `X-API-Key`: your key ID (e.g. `nx_a1b2c3...`)\n- `X-Timestamp`: current time in unix milliseconds\n- `X-Signature`: `hex(hmac_sha256(secret, timestamp + \"\\n\" + METHOD + \"\\n\" + path + \"\\n\" + query + \"\\n\" + sha256_hex(body)))`\n\nTimestamp must be within 30 seconds of server time.\n\n**The key is network-scoped; the signature is not.** The canonical string above has no network component, so the same signed request is byte-identical on every host. What stops a testnet key from authenticating against mainnet is that the key does not exist in that host's key store — sign only for the host that minted the key, and never replay a signed payload against another network. Presented to the wrong host, a key is refused with the same opaque `401` as an unknown key and must not be retried there. See “API keys are bound to one network” in the API description."},"agentAuth":{"type":"apiKey","in":"header","name":"x-agent","description":"Agent-key request signing. An agent is a secp256k1 keypair the wallet delegates trading to with `POST /agents/register`; the agent then signs each request itself, so the wallet key is never exposed. Send four headers:\n\n- `x-agent`: the agent's 20-byte address, hex, `0x` prefix optional — derived from its public key exactly like a wallet address (`keccak256(uncompressed_pubkey[1..])[12..]`). It must be registered on this host and not expired.\n- `x-timestamp`: the current time in unix milliseconds, as a base-10 integer.\n- `x-nonce`: an unsigned 64-bit integer, base 10. Required on every request; see “Nonces” for when it is enforced.\n- `x-signature`: `0x` followed by the hex of the 65-byte signature described under “Signature”.\n\n**Canonical string.** Six fields joined by LF (`\\n`), with no trailing newline:\n\n```\n{METHOD}\\n{path}\\n{query}\\n{sha256_hex(body)}\\n{x-timestamp}\\n{x-nonce}\n```\n\n- `METHOD` is upper-cased. The field order differs from `hmacAuth`: the method comes first and the timestamp comes after the body hash, so an HMAC canonical-string builder cannot be reused.\n- `path` is the logical path the server authenticates, with no host and no query string — the same rule as `hmacAuth`; see “Base paths and the signed path” in the API description.\n- `query` is the raw query string exactly as sent, without the leading `?`. With no query it is the empty string, and its line stays in the string as an empty line; it is never dropped.\n- `sha256_hex(body)` is the lower-case hex SHA-256 of the exact body bytes sent. A request with no body hashes the empty byte string (`e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`).\n- `x-timestamp` and `x-nonce` are the same decimal strings sent in those headers.\n\n**Digest.** `keccak256(utf8(canonical_string))`: raw Keccak-256 of the canonical string, **with no EIP-191 prefix and no EIP-712 structure**. A wallet library's `signMessage` / `personal_sign` adds the `\\x19Ethereum Signed Message:\\n` prefix, which produces a different digest and a signature that recovers to some other address. Sign the 32-byte hash directly (for example `eth_account`'s `unsafe_sign_hash`, or `@noble/curves` `secp256k1.sign(digest, key)`).\n\n**Signature.** Recoverable secp256k1 ECDSA over the digest, sent as 65 bytes `r (32) ‖ s (32) ‖ v (1)` with `v ∈ {27, 28}`. `s` must be low (at most half the curve order, per EIP-2). A high-S signature is refused even though it recovers the same signer, because accepting it would let one authorization be presented as two. The server recovers the signer from the digest and requires it to equal `x-agent`.\n\n**Freshness.** `x-timestamp` must be within ±30 seconds of the server's clock, on reads and writes alike. That window is the only bound on how long a captured read signature can be replayed.\n\n**Nonces.** The nonce is parsed on every request but enforced only on writes:\n\n- On a mutating method (anything but `GET`, `HEAD`, `OPTIONS` and `TRACE`), `x-nonce` must be strictly greater than the highest nonce this host has already accepted on a write from the same agent. The accepted value is persisted before the response is sent. Each agent address has its own nonce space, separate from the wallet-signed nonces of `POST /agents/register` and `POST /withdrawals`.\n- On a read, the nonce is neither checked nor consumed, so the same signed read verifies more than once inside its ±30 s window.\n\nA counter of `max(last + 1, now_ms)` is a simple nonce source: it is unique per signer and stays increasing across restarts.\n\n**Concurrent writes from one agent can be refused as replays.** The rule is about arrival order, not issue order. When two writes from the same agent are in flight together and the one with the higher nonce arrives first, the other is refused, and the refusal is the same opaque `401` as a bad signature. The fix is still being decided (ENG-17010). Until then, keep one write in flight per agent key, or register a separate agent key for each concurrent writer.\n\n**Failures are opaque.** Any failure returns the same `401` body with no reason (see the `Unauthorized` response): an unknown or expired agent, a stale timestamp, a malformed header, a wrong digest, a high-S signature or a replayed nonce all look alike. This contract does not say which check failed or in what order the checks run, and a client must not infer either. If a signer is rejected, check it against the test vector below before anything else.\n\n**What an agent key cannot do.** Agent keys are trade-only. **An agent key cannot withdraw**, and it cannot move funds off the account by any route:\n\n- `POST /api/v1/bridge/withdrawals` refuses an agent-signed request with `403` (code `AGENT_CANNOT_WITHDRAW`). The engine's withdrawal route is refused the same way.\n- `POST /withdrawals` requires the wallet's own EIP-712 signature in the body, which an agent key cannot produce.\n- The ordinary-transfer operations (`ownerSignature`) refuse any request that carries `x-agent`.\n\nAgent keys also cannot manage agent credentials: `GET /agents`, `PATCH /agents/{address}` and `DELETE /agents/{address}` refuse them with `403` (code `AGENT_KEY_FORBIDDEN`). A client that holds only an agent key manages them with the wallet's own signature instead (`walletSignature`). And they cannot mint the legacy `POST /ws-tokens` token, which is HMAC-only; use `POST /ws/token`. None of these operations lists `agentAuth`. Every operation that does list it accepts it.\n\n**Test vector.** The key below is a public test key: never fund it or register it. The `x-nexus-test-vectors` extension on this scheme carries this vector and two more (an empty-body `GET`, and a `DELETE` with a query). Together they cover both values of `v`.\n\n- private key: `0x4c0883a69102937d6231471b5dbb6204fe5129617082792ae468d01a3f362318` → `x-agent: 0x2c7536e3605d9c16a7a3d7b1898e529396a65c23`\n- request: `post /orders` (the method is lower-case on purpose; the canonical string upper-cases it), no query, body `{\"market_id\":\"BTC-USDX-PERP\",\"side\":\"Buy\",\"order_type\":\"Limit\",\"quantity\":\"0.1\",\"price\":\"50000\"}`, `x-timestamp: 1776033900123`, `x-nonce: 42`\n- canonical string (LF shown as `⏎`): `POST⏎/orders⏎⏎59ddf9017ca0eb5f8802afd1a2d1584b2d93b0260a0fcd62a1b94b3ff92b332c⏎1776033900123⏎42`\n- digest: `0xe27ade6101c417d2c393abfce8f35b6e1551cf0ce5c50dfbe12f8d6f399ffc35`\n- `x-signature: 0xeef09105834062da10d208be38311995d04cbc5e05043b89e7cbe6d4497d11b51f61729639551a8cfb6ea3e4fe0765afeba7bf3b5f5e09f63bc095c89005b61d1c`\n\n**Network scope.** Like every credential here, an agent registration belongs to the host it was registered on. The canonical string has no network component, so the refusal elsewhere comes from the agent being unknown to that host."}},"schemas":{"Order":{"type":"object","description":"An order and its lifecycle, as the read endpoints return it. Every placement option is echoed back, so this schema is also the record of how an order was placed: `postOnly`, `reduceOnly`, `stp`, `max_slippage_bps`, `triggerPrice`, the trailing anchor and offset, and the `clientOrderId` the caller supplied.\n\nField names follow CCXT's unified vocabulary wherever CCXT defines one and stay `snake_case` for the Nexus extensions it does not — the same rule `Trade` follows (ENG-13314). Money remains a decimal string rather than becoming a JSON number (EDR-012), so unlike `Trade` this schema pairs camelCase keys with decimal-string values. `POST /orders` still accepts the request vocabulary (`market_id`, `quantity`, `client_id`) and returns this one — the asymmetry is deliberate and is ENG-13524's to settle.\n\nQuantities are three figures: `amount` is the total the order was placed for, `filled` what has executed, and `remaining` their difference — served by the venue rather than left to the caller, because these are decimal strings and the subtraction is where a client loses precision (ENG-13272). All three survive an amend, which replaces the order rather than mutating it.\n\nThe four fill aggregates — `average`, `cost`, `fee` and `lastTradeTimestamp` — are `null` together when the venue cannot compute them, with `fill_totals_error` carrying the reason. They are not per-fill detail: the individual executions are on `/fills`, and on `OrderResponse` at placement time.","properties":{"id":{"type":"string","format":"uuid"},"symbol":{"type":"string"},"account_id":{"type":"string"},"side":{"type":"string","enum":["Buy","Sell"]},"type":{"type":"string"},"limit_offset_bps":{"type":["integer","null"],"description":"Fire-time limit offset in basis points, echoed for `TrailingLimit` orders (see the `OrderRequest.limit_offset_bps` placement field); null for other order types."},"stp":{"type":["string","null"],"description":"The self-trade prevention mode the order was placed with, echoed back (see the `OrderRequest.stp` placement field for what each mode does). `null` for an order placed without one, which is the default and means self-matching was allowed. One of `CancelNewest`, `CancelOldest` or `DecrementAndCancel`.\n\nDeliberately not a closed enum here, for the same reason as `cancellation_reason`: the mode set has changed before (D-026 supersedes D-014) and a mode added later must not break a client pinned to an older spec tag. `OrderRequest.stp` does enumerate the modes, because there the value is one you supply and the server validates it."},"max_slippage_bps":{"type":["integer","null"],"minimum":0,"description":"Slippage cap in basis points, echoed for orders placed with one (see the `OrderRequest.max_slippage_bps` placement field); null for orders placed without a cap."},"price":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"The order's limit price, or null for an order type that has none. CCXT defines `price` as the limit price, so ENG-13314 renamed `limit_price` to it.\n\nThis is NOT the `price` that ENG-6776 removed from this schema. That one was a phantom — documented, and emitted by neither producer, so a client branching on it got `undefined`. This property is the value the response has carried all along, now under CCXT's name for it."},"stopPrice":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"Stop price for a stop order, null otherwise."},"triggerPrice":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"The price that armed a triggered order, null for order types that are not triggered."},"stopLossPrice":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"The trigger price of a stop-loss order — CCXT's `stopLossPrice`. Set only on the stop family (`StopLimit`, `StopMarket`), where it restates the order's own `triggerPrice` under CCXT's name; null on every other order type.\n\nNexus models a bracket's stop loss as its own reduce-only child order, and records no parent→child link, so this is an order stating its OWN threshold — which is also CCXT's definition of the field. A parent order does not report its bracket's price here.\n\nTrailing types are deliberately null: their threshold is `trailing_anchor` offset by `trailing_offset_bps`, not a fixed price, so a value here would state a number the engine does not use.\n\nDOES NOT SURVIVE THE FIRE. This field is keyed on `type`, and the venue rewrites `type` when the trigger fires (`StopMarket` becomes `Market`, `StopLimit` becomes `Limit`) while retaining `triggerPrice`. The same order therefore reports a price here while it is resting and `null` once it has fired, with `triggerPrice` unchanged throughout. Reconcile a stop across its whole life on `triggerPrice`, not on this field."},"takeProfitPrice":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"The trigger price of a take-profit order — CCXT's `takeProfitPrice`. Set only on the take-profit family (`TakeProfitLimit`, `TakeProfitMarket`), where it restates the order's own `triggerPrice` under CCXT's name; null on every other order type.\n\nThe mirror of `stopLossPrice`, and null under the same conditions — see that field for why a bracket parent does not report its child's price, why trailing types state nothing, and why a FIRED take profit reports null here while keeping its `triggerPrice`."},"trailing_anchor":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"The extreme price a trailing order is measured from, null for non-trailing orders."},"trailing_offset_bps":{"type":["integer","null"],"minimum":0,"description":"Trailing distance in basis points for a trailing order; null otherwise. Echoed from placement, like `max_slippage_bps`."},"reduceOnly":{"type":"boolean","description":"Whether the order may only reduce an existing position, echoed from placement (`OrderRequest.reduce_only`).\n\nRead this rather than inferring it. The field was in every `GET /orders` response before ENG-6776 documented it — the indexer serializes the shared `Order` type verbatim — but absent from this schema, so a client needing it was guessing from order type and position side instead of reading the flag the venue recorded."},"postOnly":{"type":"boolean","description":"Whether the order was placed post-only: cancelled rather than executed if it would have taken liquidity."},"is_liquidation":{"type":"boolean","description":"Whether the liquidation engine created this order rather than the account. Liquidation fills are fee-exempt on both legs (ADR-0004), which is why a `Fill.fee` of \"0\" against such an order is a real zero and not an unstated fee."},"clientOrderId":{"type":["string","null"],"description":"The client-supplied identifier for the order, echoed back; null when placement supplied none."},"amount":{"allOf":[{"$ref":"#/components/schemas/Decimal"}],"description":"Total quantity the order was placed for, fills included. What is still executable is `remaining`, which the venue serves rather than making the caller subtract. An amend preserves it unless the amend supplies a new `size`."},"filled":{"allOf":[{"$ref":"#/components/schemas/Decimal"}],"description":"Quantity executed so far, out of `amount`. Carried across an amend, so on a replacement it still counts every fill of the order it descends from."},"remaining":{"allOf":[{"$ref":"#/components/schemas/Decimal"}],"description":"Quantity not yet executed — `amount - filled` — stated by the venue rather than re-derived by the caller. CCXT's unified `remaining`.\n\nDerivable, and served natively anyway (ENG-13272). Quantities here are decimal strings (EDR-012), so a caller subtracting them in JavaScript converts through a float first and can land a value that is wrong in the last places — which is what consumers do today. The engine already holds this figure exactly, so the venue reports it and the subtraction happens once, in decimal, rather than once per client.\n\nIt is the arithmetic difference at all times, NOT an assertion that the quantity is still working. A cancelled, expired or rejected order reports the quantity that never executed, not a quantity still on the book; `status` is what distinguishes those, and a client sizing a replacement order should read both. `0` on a fully filled order.\n\nCarried across an amend on the same terms as its two operands: `PATCH /orders/{order_id}` preserves `amount` unless the amend supplies a new `size`, and carries `filled` across, so the difference stays consistent with the pair on the same response. Unlike the four fill aggregates it is never `null` and has no `fill_totals_error` case — it needs no fill history to compute, only the order's own two quantities."},"status":{"type":"string","description":"Lifecycle state. `Triggered` is a transient engine state stamped on a stop/take-profit/trailing order at the moment it fires, before the resulting order is submitted; no client-facing response is expected to carry it, because every submit outcome overwrites it (`Open`/`PartiallyFilled` when the converted order rests, `Filled`, `Cancelled`, or `Rejected`). It is listed because the wire type can hold it, so a consumer that rejects unknown values would fail on it rather than degrade. Treat this set as growable and prefer tolerating an unrecognised status to hard-failing.","enum":["Open","PartiallyFilled","Filled","Cancelled","Expired","Rejected","Triggered"]},"cancellation_reason":{"oneOf":[{"type":"null","description":"The order has not reached a terminal status, or no cause was recorded."},{"type":"string","description":"Any cause other than self-trade prevention, as a bare string."},{"type":"object","description":"A cause that carries a payload. Exactly one key, naming the cause. `additionalProperties` is deliberately not closed, so a cause added later does not invalidate this schema.","minProperties":1,"maxProperties":1,"properties":{"Stp":{"type":"string","description":"Self-trade prevention cancelled the order; the value is the STP mode that fired (`CancelNewest`, `CancelOldest` or `DecrementAndCancel`)."}}}],"description":"Why the order reached a terminal `Cancelled` or `Rejected` status. `null` for every other status, and for a terminal order the engine recorded no cause for. The key is always present.\n\n**Two wire shapes.** The engine's reason type is an externally tagged enum, so every cause except self-trade prevention is a bare string, while self-trade prevention is a single-key object naming the mode that fired: `{\"Stp\": \"CancelNewest\"}`. Branch on the JSON type before reading the value.\n\nThe string form is one of `User` (an explicit cancel or cancel-all), `SlippageCap` (a market order's running fill VWAP left the `max_slippage_bps` band — see that field), `Liquidation` (cancelled ahead of a liquidation, or the unfilled remainder of one), `Expired` (an IOC, FOK or market remainder that cannot rest on the book), `MarketHalt`, `AmendReplace` (carried on the *original* order of an atomic cancel-replace via `PATCH /orders/{order_id}`), `InsufficientLiquidity` (a stop, stop-limit or trailing stop fired into an empty opposite side), `BracketClosed` or `BracketFlipped` (a bracket child whose parent position closed to zero or flipped sign), or `PriceBandExceeded` (the order-vs-mark price-band collar rejected it). The object form's only key today is `Stp`, whose value is `CancelNewest`, `CancelOldest` or `DecrementAndCancel`.\n\n**Treat the value as open.** Causes are added as the engine gains them, and this is not a closed enum: match the ones you handle and surface anything else verbatim rather than failing to parse. A client pinned to an older spec tag will meet causes it does not know.\n\n`GET /orders/history` reports the same causes in a **different encoding** — `OrderHistoryEntry.cancellation_reason` is always a string and renders the self-trade case as `Stp(CancelNewest)`, not as an object. Do not compare values across the two surfaces."},"timeInForce":{"type":"string"},"timestamp":{"allOf":[{"$ref":"#/components/schemas/TimestampMs"}],"description":"When the order was created, in epoch milliseconds. Named `created_at` until ENG-13314 renamed it to CCXT's `timestamp`. `datetime` beside it renders the same instant as a string."},"datetime":{"type":"string","format":"date-time","description":"`timestamp` as an ISO 8601 string in UTC, to millisecond precision. Derived from that same value rather than recorded separately, so the two cannot describe different instants. CCXT declares both; read whichever suits the client."},"lastUpdateTimestamp":{"allOf":[{"$ref":"#/components/schemas/TimestampMs"}],"description":"When the order was last modified, in epoch milliseconds. Named `updated_at` until ENG-13314 renamed it to CCXT's `lastUpdateTimestamp`."},"average":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"Volume-weighted average price of this order's fills, as a decimal string. `null` when the order has not filled (`fill_totals_error` is then also `null` — nothing executed is an answer), or when the totals cannot be stated — see `fill_totals_error`."},"cost":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"Total quote value executed on this order (Σ price × size), as a decimal string. Same availability rule as `average`."},"fee":{"anyOf":[{"$ref":"#/components/schemas/Decimal"},{"type":"null"}],"description":"Total fee for this order as a signed decimal string: positive is a charge, negative a net maker rebate. `null` when the totals are unavailable, **and also when they are available but a contributing fill stated no fee** — a total is a claim about every fill, so one unstated leg makes the total unknown rather than smaller. Absent is never zero. `POST /orders` returns `null` here even alongside a populated `average`: that response is built from the match result, which carries no fee attribution."},"lastTradeTimestamp":{"anyOf":[{"$ref":"#/components/schemas/TimestampMs"},{"type":"null"}],"description":"Timestamp of this order's most recent fill, in epoch milliseconds. Same availability rule as `average`."},"fill_totals_error":{"type":["string","null"],"description":"Machine-readable reason `average` / `cost` / `fee` / `lastTradeTimestamp` are `null`, or `null` when they are populated **or** when the order simply has not filled. One channel for all four because they are one aggregate with one cause.\n\n`fills_retention_exceeded` — a fill of this order has aged out of the retained history, so any total would be a partial sum. A partial average is a real-looking price with nothing marking it wrong, so it is withheld.\n\n`fill_history_predates_amend` — the retained fills fall short of this order's `filled`, on a response for an order id the venue minted answering this same request. `PATCH /orders/{order_id}` is an atomic cancel-replace: it mints a new order id and carries `filled` across, while fills stay attributed to the id that executed them, so the replacement counts executions it has no history of and the totals would describe only the post-amend portion. Served only where the amend is the sole possible cause — a read route reports `fill_history_short_of_filled_qty` for the same shortfall.\n\n`fill_history_short_of_filled_qty` — the retained fills for this order id are complete as far as the retention window can tell, and still sum to less than its `filled`. Two causes produce this and they cannot be told apart here: the order descends from an amend (see `fill_history_predates_amend`), or its per-order aggregate was evicted from a bounded map and rebuilt from later fills alone, which is a retention drop the window test cannot see. The reason states the shortfall rather than naming a cause it would be guessing at, because the two have different remedies. As with every value here no partial total is served: the four fields stay `null`.\n\n`fill_history_not_retained` — the producer answering this request keeps no per-order fill history, so the totals are not derivable here even though the order has executed. Distinct from `fills_retention_exceeded`, which means a retained history dropped a fill. Reaches a client on the responses relayed from the matching engine without a fill-history join: `DELETE /orders/{order_id}`, `DELETE /orders`, and the duplicate-`client_id` replay branches of `POST /orders` and `POST /orders/batch`, which return an order the request did not create. `PATCH /orders/{order_id}` is enriched before it leaves the venue and reports `fill_history_predates_amend` instead.\n\n`filled_qty_lags_fill_history` — the retained fills for this order id sum to MORE than its `filled`, so the totals would answer for more executions than the order itself admits to. Neither a shortfall nor a retention problem: the venue folds a match's fill and the taker order's own `filled` from two separate events, so a read landing between them sees a fill history ahead of the order's projection. It closes itself within one event — retry the read. The four fields stay `null` until then, and a `filled` of `0` carrying this cause means the same thing rather than an order that has not executed: fills are known for the id, the order has simply not caught up yet."}}},"Decimal":{"type":"string","description":"Arbitrary-precision decimal serialized as a string (lossless). Parse with a decimal type, never a float."},"TimestampMs":{"type":"integer","format":"int64","description":"Unix epoch timestamp in milliseconds."}},"responses":{"Unauthorized":{"description":"Authentication failed. All 401 responses return the same opaque body to prevent information leakage. A credential minted on a different network is one of the causes it hides — by design, so that a key id cannot be probed for existence on another network. Do not retry it against another host.","content":{"application/json":{}}}}},"paths":{"/orders/{order_id}":{"get":{"tags":["Account"],"summary":"Get order by ID","operationId":"fetchOrder","parameters":[{"name":"order_id","in":"path","required":true,"schema":{"type":"string","format":"uuid"}},{"name":"market_id","in":"query","required":true,"schema":{"type":"string"},"description":"Market the order rests on (required for routing)."}],"responses":{"200":{"description":"The requested order.","content":{"application/json":{"schema":{"$ref":"#/components/schemas/Order"}}}},"401":{"$ref":"#/components/responses/Unauthorized"},"404":{"description":"No such order for this account: the id was never placed by this account, or it refers to a terminal order older than the 500-per-account retention window. A 404 is deliberately identical for \"never existed\" and \"not yours\" (ownership masking). It no longer means \"not currently resting\" — recently terminal orders return 200 (ENG-10962)."}},"description":"Resolves any order the account placed: resting orders come from the matching engine's authoritative book state, and recently completed orders (filled, cancelled, rejected, expired) are served from the indexer's terminal-order mirror, so an order that fills instantly can still be fetched by the id its placement returned (ENG-10962). The mirror retains the most recent 500 terminal orders per account — the same window `GET /orders/history` lists — so anything listable is fetchable. Older terminal orders resolve only through `GET /orders/history`."}}}}
````
**Test it** cannot sign this request. `X-Signature` is an HMAC computed per call: see [Authentication](/api-reference/guides/authentication.md), or use an SDK.
***
API version `0.9.131`
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.nexus.xyz/api-reference/account/fetch-order.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.