---
title: "Build Order"
method: POST
path: "/v0/trade/build-order"
tags: ["Trading"]
---

# Build Order

`POST /v0/trade/build-order`

Build an order *without* placing it. Returns the order's typed-data payload (for the wallet to sign) plus a `built_order_id` to pass to `submitOrderHosted` once it's signed.

Use this when you want a human to approve each trade before it submits — for example, surfacing the order details in a wallet popup. For everything else, use `createOrderHosted`, which builds + signs + submits in one call.

## Request body

- BuildOrderHostedRequest — Hosted build-order request. Identify the target outcome by passing `venue` + `venue_outcome_id` from `client.fetch_markets()` (the SDK does this automatically when you pass `outcome=` to `create_order` or `build_order`).
  - `venue` 'polymarket' | 'opinion' | 'limitless' — Venue the outcome trades on. Inferred automatically from your client class in the SDKs.
  - `venue_outcome_id` string — The outcome's identifier (e.g. Polymarket `tokenId`, Opinion outcome hash, or Limitless token address). Returned by `client.fetch_markets()`.
  - `side` 'buy' | 'sell', required — Direction of the order. `buy` opens or adds to a long position on the outcome; `sell` closes or reduces it.
  - `order_type` 'market' | 'limit' — `market` fills immediately at the best available price (subject to `slippage_pct`); `limit` rests on the venue's order book at `price` until matched or cancelled.
  - `amount` number, required — Order size. For `market` buys, in USDC dollars (the budget you want to spend). For `market` sells and all `limit` orders, in outcome shares.
  - `denom` 'shares' | 'usdc' — Unit `amount` is denominated in. `shares` = outcome shares; `usdc` = USDC dollars. Market buys require `usdc`; market sells and limit orders require `shares` (the server validates this combination).
  - `price` number, nullable — Required for `limit` orders. Probability in [0, 1] -- e.g. `0.55` means buying / selling shares at 55 cents each. Ignored for `market` orders.
  - `slippage_pct` number, nullable — Maximum acceptable slippage as a percent. Use aggressive defaults (`30` for buys, `99.9` for sells) until the upstream economic validator tightens -- lower values frequently trip precision checks. Ignored for market orders, which pin worst-price to the domain extreme; the server defaults to `20` when omitted.
  - `user_address` string, required — EVM wallet address that will sign the resulting typed data. Must match the wallet whose USDC funded the PMXT PreFundedEscrow on Polygon.

## Response `200`

Built order with typed data to sign.

- BuildOrderHostedResponse — Hosted build-order response. The caller must sign `typed_data` locally (and `pull_typed_data` if present) and POST the signatures back via `submitOrderHosted` before the order expires.
  - `built_order_id` string, required — Opaque server-side key used by `submitOrderHosted` to look up the build context.
  - `side` 'buy' | 'sell', required — Echo of the order side from the request.
  - `typed_data` object, required — EIP-712 typed-data payload to sign locally with the wallet key matching `user_address`. Return the signature in `SubmitOrderHostedRequest.signature`.
  - `pull_typed_data` object, nullable — Optional secondary EIP-712 payload for venues that require a separate pull-authorization (notably Polymarket neg-risk markets and sell orders). Sign with the same wallet and return in `SubmitOrderHostedRequest.pull_signature`. `null` when not required.
  - `quote` object, required — Pre-trade quote: expected average fill price, slippage, and fees.
    - `best_price` number — Top-of-book price on the side you are trading against (best ask for buys, best bid for sells), in probability units [0, 1].
    - `expected_avg_price` number — Volume-weighted average fill price across the order-book levels that would be consumed, in probability units.
    - `expected_slippage_pct` number — Expected slippage from `best_price` to `expected_avg_price`, expressed as a percent.
    - `estimated_cost_or_proceeds` number — Estimated USDC dollars to be spent (for buys) or received (for sells), net of fees.
    - `fillable` boolean — `true` when the venue currently has enough resting liquidity to fill the requested size at-or-better than the implied worst price.
    - `liquidity` number — Total resting liquidity on the relevant book side, in USDC dollars.
    - `fee_amount` number — Estimated PMXT + venue fee for the order, in USDC dollars.
    - `tick_size` string — Minimum price increment on the venue's order book, as a decimal string (e.g. `"0.01"`).
  - `resolved` object, nullable — Venue-side fields resolved from the supplied outcome — token ids, contract addresses, etc. Useful when you want to cross-reference the order against the venue's own API. `null` if resolution failed.
    - `venue` 'polymarket' | 'opinion' | 'limitless' — Venue the order will execute on.
    - `token_id` string — Venue-native outcome identifier (Polymarket ERC-1155 `tokenId`, Opinion outcome hash, or Limitless token address).
    - `neg_risk` boolean — `true` when the market uses Polymarket's neg-risk contract (which requires the secondary `pull_typed_data` signature).
    - `tick_size` number — Minimum price increment on the venue's order book, in probability units (e.g. `0.01`).
    - `opinion_market_id` integer, nullable — Opinion-native integer market id. `null` for Polymarket and Limitless orders.

## Other responses

- `401` — Invalid or missing PMXT API key.
- `403` — Insufficient escrow balance to back the requested order size.
- `404` — Outcome not found in the catalog.
- `422` — Invalid order parameters (e.g. price out of range, denom mismatch).
- `503` — Catalog unavailable -- temporary upstream failure.

---

[API](https://skmtc.net/pmxt-dev/apis/pmxt-hosted-router-api.md) · [All operations](https://skmtc.net/pmxt-dev/apis/pmxt-hosted-router-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/pmxt-dev/pmxt-hosted-router-api/versions/9ee3cbe2dc87/schema)