Place an order routed across every venue holding the same outcome.
Identifies the outcome byDocumentation Index
Fetch the complete documentation index at: https://docs.predexon.com/llms.txt
Use this file to discover all available pages before exploring further.
predexonId instead of venue + market — the router splits the order across the venues that hold equivalent positions, picking the fee-aware best fill. Each leg is dispatched to its matching venue; the response carries the per-leg fills.
Set bridgeEnabled: true on a market buy to let the router top up the target venue from your account’s deposit wallet if its balance is short. Bridge slippage is bounded internally. bridgeEnabled is rejected on limit orders and sells.
The response uses a single shared envelope (same shape as GET endpoints), plus a summary aggregate and — on a full failure — an errorCode. limitPrice is null on market orders; read the executed price from summary.avgPrice (weighted across legs) or fills[].price (per leg).
Pass clientOrderId as a safe-to-retry key — it’s forwarded to each bridge leg and venue plane so retries don’t double-bridge or double-place at the venue. The router itself does not currently dedupe by clientOrderId, so two simultaneous POSTs with the same key can both proceed; serialize retries client-side.
?explain=true to the URL to receive a _routing.considered[] array on the response — per-venue projection (top-of-book, fee at top, dropped reason) for every venue the router considered, including ones dropped from the final split. Default response stays slim; opt in when you need to audit “why did the router pick this split?”.Set to true to receive a _routing.considered[] audit array on the response — per-venue projection (top-of-book, fee at top, dropped reason) for every venue the router looked at. Defaults to false for a slim response.
Canonical outcome identifier — the router routes across every venue holding it.
buy, sell market, limit USD notional. Required for market buy.
Share count. Required for market sell and all limit orders.
Limit price in (0, 1). Required for limit orders.
Partner-supplied key forwarded to bridge legs and venue planes for safe retries. Not used for router-level deduplication.
Market buy only. When true, the router tops up the target venue from the account's deposit wallet if the venue's balance is short. Rejected with 400 on limit orders and sells. Bridge slippage is bounded internally.
Router order created.
Partner-facing router-order envelope. Same shape across POST /router/orders (market + limit), GET /router/orders (list rows), and GET /router/orders/{routerOrderId}. POST adds errorCode on 502. GET detail adds decisionSnapshot on limit orders.
Stable handle for GET/cancel.
Canonical outcome identifier.
Display title for the outcome (the market question).
Display label for the side bet on (e.g., Yes, Lakers).
buy, sell market, limit Roll-up across legs. partial whenever any leg filled or partial-filled while at least one leg is still open or another mix produced movement.
open, partial, filled, cancelled, failed Present only on 400 from POST /router/orders when every dispatched leg failed; absent on success and GET responses. Per-leg failure reasons are on fills[].error.
all_venues_failed USD notional the partner sent. Populated on market buys; null otherwise.
Share count the partner sent. Populated on market sells and all limit orders; null otherwise.
Limit price the partner set. null on market orders — for the executed price on a market order, read summary.avgPrice (weighted across legs) or fills[].price (per leg).
ISO 8601 timestamp of order creation.
Per-venue legs. The source of truth for per-leg status — status here can be open (limit resting), partial, filled, cancelled, or failed. A cancelled leg with size > 0 means partial-fill-then-cancel.
Aggregate stats across fills[]. Embeds the partial/cancelled accounting logic so partners don't have to re-derive it.
GET detail only, for limit orders. Snapshot of the order book at decision time so you can audit the routing choice. null for market orders and pre-rollout records.
Opt-in routing audit. Present only when the request included ?explain=true. Surfaces every venue the router considered, including dropped venues with their reason.