Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.predexon.com/llms.txt

Use this file to discover all available pages before exploring further.

You’re building a product where end-users place trades. Could be a copytrading app, structured products, a prediction-market UX, an agentic platform, or a brokerage. This guide is about the architecture decisions — Predexon handles custody, signing, and routing so you don’t have to. You’ll be ready to:
  • Pick the right account model for your product (one account per user, vs. corporate)
  • Wire up funding, withdrawals, and cross-chain bridging
  • Place orders via the Unified Order Router or per-venue
  • Monetize with partner fees
  • Handle errors, retries, and latency expectations realistically

​
Pick an account model

Every account on the Trading API owns its own set of per-venue managed wallets. Two patterns:

Account per end-user (recommended)

Each of your users gets their own Predexon account. Funds, positions, and P&L are isolated per user. You hand them their deposit wallet; they deposit on-chain. Best for copytrading, brokerage UX, anything user-facing.API key strategy: one Predexon API key for your platform; each end-user maps to an accountId you create on their behalf.

Corporate account (single)

One Predexon account holds all platform funds. Your platform tracks per-user balances internally and bills/credits users out-of-band. Best for funds, prop trading desks, internal tools.API key strategy: one Predexon API key, one accountId, your DB owns the ledger.
There’s no third option from Predexon’s side — these are the two shapes. Pick based on whether end-user funds need to be on-chain-isolated or whether you can custody them off-chain.
Account limits per API key: Free 5 · Dev 50 · Pro 1,000 · Enterprise custom. Account-per-user platforms typically run on Pro or Enterprise.

​
The four-step trading flow

Every integration walks the same four steps. Code skeleton below uses Python; full per-step references linked. 
import os, requests
HEADERS = {"x-api-key": os.environ["PREDEXON_API_KEY"], "Content-Type": "application/json"}
BASE = "https://trade.predexon.com"

# 1. Create account
account = requests.post(f"{BASE}/api/accounts/create", headers=HEADERS).json()
account_id = account["accountId"]

# 2. Enable venue(s)
requests.post(
    f"{BASE}/api/accounts/{account_id}/enable",
    headers=HEADERS,
    json={"venue": "polymarket"},
)

# 3. Fund (user deposits USDC on Base, then move to venue)
info = requests.get(f"{BASE}/api/accounts/{account_id}/deposit-info", headers=HEADERS).json()
# ... user sends USDC to info["address"] ...
requests.post(
    f"{BASE}/api/accounts/{account_id}/transfers",
    headers=HEADERS,
    json={"from": "deposit", "to": "polymarket", "amount": "100"},
)

# 4. Trade (per-venue, or via the router)
order = requests.post(
    f"{BASE}/api/accounts/{account_id}/orders",
    headers=HEADERS,
    json={"venue": "polymarket", "market": {"tokenId": token_id},
          "side": "buy", "type": "limit", "size": "10", "price": "0.50"},
).json()
StepReferenceNotes
Create accountCreate AccountIdempotent if you pass your own clientId. Persist accountId.
Enable venueEnable VenueProvisions wallet via Turnkey. Async — poll Get Account until status: "active" (typically <30s).
FundFunding & Withdrawals guideDeposit wallet is Base USDC. Bridge from any chain via Quote Transfer.
TradePlacing Trades guidePer-venue or via Order Router.

​
Unified Order Router vs venue-specific

This is the single most important architecture choice in your product.

Use the Order Router when…

Your user wants exposure to an outcome and doesn’t care which venue fills it. The router compares price + fees across every venue holding the canonical outcome and picks the best fill. Perfect for casual UX, structured products, agentic trading.

Use venue-specific orders when…

Your user picked the venue intentionally (e.g. copytrading a Kalshi trader), or you need native order types not exposed by the router. Full control, normalized response shape.
You can mix both in the same account. Many products use the router for new positions and per-venue for management (cancels, takes on a specific venue).

​
Funding architecture

Funding is the single hardest part to get right. The rules:
  • Every account has one deposit wallet — Base USDC. This is your end-user’s “main” address.
  • Venue balances are separate — funding Polymarket means moving USDC from deposit → polymarket wallet (which gets converted to pUSD).
  • Cross-chain bridging is supported via Quote Transfer — get a signed transaction, your user submits from their own wallet. Supports Ethereum, Arbitrum, Polygon, BSC, Optimism.
  • Hyperliquid is the exception — it uses Across for funding, not /transfers. See Funding guide.
  • Withdrawals are the same path in reverse — drain venue → deposit, then /transfers with to: "external".
For an account-per-user platform, you’ll typically:
  1. Show user their deposit address (Base USDC) on signup
  2. Show them a “Deposit from another chain” CTA that calls quote-transfer and prompts a wallet signature
  3. Auto-route deposits into the venue they want to trade on (background /transfers call after deposit confirms)

​
Monetize with partner fees

Every order placed through an account you own can carry a partner fee that lands in your wallet. Currently supported on Polymarket (more venues coming). 
# Set a 0.5% partner fee on all Polymarket fills
requests.put(
    "https://trade.predexon.com/api/fees/policy",
    headers=HEADERS,
    json={
        "polymarket": {
            "feeBps": 50,  # 0.5%
            "destination": "0xYourWallet"
        }
    },
)
See Fees & Monetization guide for per-venue rates, settlement schedule, and the Set Fee Policy reference.

​
Latency, errors, and operational realism

What to expect in production:
SurfaceTypical latencyNotes
Trading API (place order)200–800msHigher for first call after venue enable (warm-up).
Trading API (cancel)200–500ms
Order Router (place)400–1500msHas to quote venues sequentially, then place.
Data API (read)50–200ms
WebSocket events<1s end-to-endPending-trades lead confirmed-trades by 3–5s.
Error patterns you’ll see most:
  • 409 Conflict on fee policy updates — concurrent modification. Retry.
  • 400 on order placement with insufficient venue balance — surface this to user, prompt to fund.
  • 503 rarely — surface as “venue temporarily unavailable” and let users retry; don’t retry yourself.
See Best Practices for retry/backoff patterns and idempotency.

​
Common builder recipes

Copy-trade a wallet

Subscribe to a wallet’s trades via WebSocket, mirror them into your user accounts via the router.

Cross-venue arbitrage product

Surface arb spreads to users, execute both legs atomically through the router.

Portfolio monitor

Positions + P&L + live updates. Same patterns power most prediction-market UIs.

Execution overview

Full map of the Trading API surface.

Order Router guide

The headline feature — canonical discovery, quoting, routing.

Funding & withdrawals

Every funding path, per venue, including cross-chain bridging.

Best Practices

Retries, idempotency, rate limits, error handling.