Skip to main content

​
Overview

The Predexon Order Router lets partners trade an outcome across every venue that lists it with one API call. A single request is split across Polymarket, Predict.fun, Opinion, and Limitless; the router compares prices, executes against the best available liquidity, and returns one unified response. There is no venue selection, no per-venue token handling, and no manual splitting. Partners identify outcomes by predexon_id — the same canonical identifier used by the Sports Discovery API. Base URL: https://trade.predexon.com All endpoints are served under /api/accounts/{accountId}/router/* and require your trading key in the x-api-key header.

​
Trading Accounts

Every router call is scoped to an accountId. A trading key may own one or many accounts, and an account holds the per-venue balances and positions the router reads and writes against. You provision accounts before placing your first order — the router does not create accounts implicitly. Account creation, funding, per-venue enablement, and the rest of the lifecycle live in the Trading API accounts docs. Accounts are isolated per trading key — a key can only operate on accounts it created.

​
Routed Venues

VenueStablecoin
PolymarketUSDC
Predict.funUSDT
OpinionUSDT
LimitlessUSDC

​
Addressing Outcomes with predexon_id

A predexon_id is Predexon’s canonical identifier for a single tradeable outcome. It is no longer a venue-specific identifier. Partners get canonical predexon_ids from the Sports Discovery API:
  • GET /v2/sports/games — compact game/outcome list with canonical predexon_ids.
  • GET /v2/sports/markets — per-venue listings with the same canonical predexon_id on matched outcomes.
  • GET /v2/sports/outcomes/{predexon_id} — resolves a canonical outcome ID to every venue listing for that outcome.
Pass the canonical predexon_id for the outcome, and your order executes across every routed venue that lists that same outcome. Venue-native identifiers such as Polymarket token IDs, CTF condition IDs, and Kalshi tickers are still returned for transparency and direct venue execution, but the router input is the canonical predexon_id.

​
Placing Orders

Today the router supports market orders. Specify:
  • predexonId — the outcome.
  • side — buy or sell.
  • Either amount (stablecoin notional, for buys) or size (shares, for sells).
A market order fills immediately at the best available price across routed venues. A single request may split across multiple venues — partial fills and partial failures are normal. The fills[] array breaks down what happened per venue; summary.venuesUsed and summary.venuesFailed give the aggregate picture. A 201 Created response can still contain failed fills — inspect per-venue status before treating the order as fully executed.

​
Quote Before You Execute

The /router/quote endpoint simulates a fill using the same routing logic as a live order. Use it to preview expected price, see the per-venue breakdown, and check fill likelihood (high / medium / low relative to requested size) before committing. Calling Quote is optional — partners can go straight to Place Order.

​
Fees

The router walks fee-inclusive order books when ranking venues, so the cheapest nominal price is not always the best effective price. Each venue’s effective fee at the current top of book is surfaced as feeBpsAtTop on both /quote and /orders — partners don’t compute fees themselves; the router factors them into its ranking.

​
Positions

GET /router/positions aggregates the account’s open positions by predexon_id across every routed venue. Each position surfaces once, with per-venue breakdowns preserved under venues[]. Every position carries cost basis (averagePrice), live market value (currentPrice, currentValue, pnl), and lifecycle state (status, result). When one venue fails to respond, healthy venues still return — check _meta.venues[] for per-venue read status.

​
Authentication & Rate Limiting

All requests require your trading key in the x-api-key header. Trading and data are separate keys — your trading key authorizes write paths on trade.predexon.com, and your data key authorizes the Sports Discovery API on api.predexon.com. Contact the Predexon team to obtain either. Accounts are isolated per trading key — you can only access accounts created with that key. Requests are rate-limited per key on a per-minute basis; the limit depends on your tier. A 429 Too Many Requests includes a Retry-After header — wait the specified interval and retry.

​
Errors

Every error response carries a human-readable error string and a machine-readable errorCode: 
{ "error": "Human-readable error message", "errorCode": "machine_readable_code" }
Full error code tables live on each endpoint’s reference page. For support, propagate the x-request-id response header — the router echoes it on every response so we can correlate your call with our logs.