The Order Router lets you trade an outcome without picking a venue. Identify 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 — a stable identifier shared across venues — and the router splits the order across every venue that lists it, picking the fee-aware best fill.
When to use it
| You want to… | Use |
|---|---|
| Trade a specific venue, with your own market identifiers | Place Order on the accounts path |
| Trade an outcome, wherever the best price is | Router |
| Quote expected fill before committing | Get Quote |
Step 1: Find a predexon_id
Every outcome in the Data API carries apredexon_id field (the Data API uses snake_case; the Trading API accepts and returns it as predexonId). The same outcome on different venues shares the same identifier when our canonical matching graph has linked them.
Python
Step 2: Get a quote (optional, recommended)
Get Quote projects how an order would fill across every venue holding the outcome. Use it to sanity-check expected price and fill likelihood before placing.Python
Step 3: Place a router order
Python
routerOrderId, predexonId, title, outcome, status, createdAt, etc.), the per-venue fills[], and a summary aggregate. On a market order, summary.avgPrice is the executed weighted-average price. On full failure the response status is 502 with errorCode: "all_venues_failed".
Bridge-enabled buys
By default, the router only uses balances already sitting at each venue. PassbridgeEnabled: true on a market buy to let the router top up the target venue from your deposit wallet if it’s short. Bridge slippage is bounded internally. The flag is rejected on limit orders and sells.
Python
Step 4: Monitor and cancel
Python
cancelled, not_found (already filled or cancelled), already_filled, or failed.
Retries
PassclientOrderId as a safe-to-retry key. It’s forwarded to each bridge leg and to the venue plane so retries don’t double-bridge or double-place at the venue. The router does not currently dedupe by clientOrderId at the order level, so two simultaneous POSTs with the same key can both proceed — serialize retries client-side.
Auditing routing decisions
Default responses stay slim — just fills and summary. Pass?explain=true on either POST /router/orders or GET /router/orders/{routerOrderId} to receive a _routing.considered[] array detailing every venue the router considered, with per-venue top-of-book, fee, and (on POST) projected fill.
Python
decisionSnapshot on GET detail carries the full per-venue book state at decision time. ?explain=true on GET produces the same _routing.considered[] shape POST emits, but avgPrice and feeBpsAtTop are null on the GET path (not recoverable from a snapshot alone).
Next Steps
Quote Reference
Full endpoint schema
Place Order Reference
Full endpoint schema
Funding & Withdrawals
Required for
bridgeEnabled buys