Skip to main content
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 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)
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 order placement.

​
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
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.

Cross-venue arbitrage product

Surface arb spreads to users across venues.

Portfolio monitor

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

Execution overview

Full map of the Trading API surface.

Funding & withdrawals

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

Best Practices

Retries, idempotency, rate limits, error handling.