Skip to main content

​
How it works

The order router is the shared trading surface for both traders and builders. You use the same order endpoints either way. The only builder-specific delta is impersonation and optional fee escrow on create-order requests.

​
Authentication modes

ModeHow credentials workBest for
Stored (self onboard)POST /onboard once with your credentials, trade foreverMost users
Managed walletPOST /onboard with mode: "managed", we handle keysUI traders
Per-requestPass creds per-request via X-Exchange-Credentials headerPro traders, builders
Builder impersonationX-Builder-Customer-Id header routes to end-userBuilders

Direct Trader

Store credentials and trade via API.

Managed Wallet

We create and manage a wallet for you.

Per-Request

Pass credentials with each request.

​
First trade checklist

  1. Pick an auth mode from Trading Setup.
  2. Onboard the exchange first if you are using stored or managed credentials.
  3. Find the market with /markets, then inspect liquidity with /execution-price or /orderbook.
  4. Place the order with POST /orders.
  5. Monitor status with /orders, /fills, and /positions.

​
For Traders

If you are trading your own account, pick one credential mode from Trading Setup, onboard if needed, then use the normal order endpoints directly with your API key.

​
Order lifecycle

1. POST   /orders?exchange=X     → Create order (returns Order with status)
2. GET    /orders?exchange=X     → List open orders
3. GET    /orders/:id?exchange=X → Poll order status
4. DELETE /orders/:id?exchange=X → Cancel order

​
Order types

TypeBehaviorSupported
gtcGood-til-cancelled (default)All exchanges
iocImmediate-or-cancelPolymarket, Kalshi
fokFill-or-killPolymarket
Set via params.order_type in the create order request body. Unsupported combinations return 501.

​
Supported exchanges

ExchangeTradingPositionsBalanceFillsOrderbookPrice HistoryOnboarding
PolymarketYesYesYesYesYesYesManaged + Self
KalshiYesYesYesYesYesYesSelf
LimitlessData only———YesYes—
OpinionData only———PollingYes—
Predict.funData only———PollingYes—
Trading support (create/cancel orders, positions, balance, fills) requires exchange credentials. Credentials can be stored via POST /onboard (Polymarket and Kalshi) or passed per-request via X-Exchange-Credentials. Use GET /exchanges to see the full capability matrix at runtime.

​
For Builders

Builders route orders on behalf of end-users by adding the X-Builder-Customer-Id header. All order endpoints work the same — Parsec resolves the end-user’s credentials automatically. 
curl -X POST "https://api.parsecapi.com/api/v1/orders?exchange=polymarket" \
  -H "X-API-Key: pk_live_YOUR_BUILDER_KEY" \
  -H "X-Builder-Customer-Id: CUSTOMER_ID" \
  -H "Content-Type: application/json" \
  -d '{ "market_id": "0x...", "outcome": "Yes", "side": "buy", "price": 0.55, "size": 100 }'
Read-only endpoints such as /markets, /orderbook, /trades, /price, and /events do not require X-Builder-Customer-Id. For fee collection on builder orders, include the fee_auth object in the create order request. See Fee Escrow and the Create Order reference for the full field list. For the full builder flow, use:

​
Pre-trade checks

Before placing an order, you can use these endpoints to assess liquidity and readiness:
EndpointPurpose
GET /execution-priceEstimate VWAP + slippage for a hypothetical order
GET /orderbookInspect the live orderbook
GET /pingVerify exchange connectivity and auth status