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

# App builder & platform

> Architecture patterns, account models, and the full execution stack for products that place trades on behalf of users.

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:

<CardGroup cols={2}>
  <Card title="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.
  </Card>

  <Card title="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.
  </Card>
</CardGroup>

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.

<Note>
  **Account limits per API key**: Free 5 · Dev 50 · Pro 1,000 · Enterprise custom. Account-per-user platforms typically run on Pro or Enterprise.
</Note>

***

## The four-step trading flow

Every integration walks the same four steps. Code skeleton below uses Python; full per-step references linked.

```python theme={null}
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()
```

| Step           | Reference                                                                  | Notes                                                                                                       |
| -------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Create account | [Create Account](/trading-api/accounts/create-account)                     | Idempotent if you pass your own `clientId`. Persist `accountId`.                                            |
| Enable venue   | [Enable Venue](/trading-api/accounts/enable-venue)                         | Provisions wallet via Turnkey. Async — poll `Get Account` until `status: "active"` (typically `<30s`).      |
| Fund           | [Funding & Withdrawals guide](/trading-api/guides/funding-and-withdrawals) | Deposit wallet is Base USDC. Bridge from any chain via [Quote Transfer](/trading-api/funds/quote-transfer). |
| Trade          | [Placing Trades guide](/trading-api/guides/placing-trades)                 | Per-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](/trading-api/funds/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](https://across.to) for funding, not `/transfers`. See [Funding guide](/trading-api/guides/funding-and-withdrawals#hyperliquid).
* **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).

```python theme={null}
# 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](/trading-api/guides/fees-and-monetization) for per-venue rates, settlement schedule, and the [Set Fee Policy](/trading-api/fees/set-fee-policy) reference.

***

## Latency, errors, and operational realism

What to expect in production:

| Surface                   | Typical latency  | Notes                                               |
| ------------------------- | ---------------- | --------------------------------------------------- |
| Trading API (place order) | 200–800ms        | Higher for first call after venue enable (warm-up). |
| Trading API (cancel)      | 200–500ms        |                                                     |
| Data API (read)           | 50–200ms         |                                                     |
| WebSocket events          | `<1s` end-to-end | Pending-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](/start-here/best-practices) for retry/backoff patterns and idempotency.

***

## Common builder recipes

<CardGroup cols={2}>
  <Card title="Copy-trade a wallet" icon="users" href="/start-here/cookbook/copy-trade-wallet">
    Subscribe to a wallet's trades via WebSocket, mirror them into your user accounts.
  </Card>

  <Card title="Cross-venue arbitrage product" icon="scale-balanced" href="/start-here/cookbook/cross-venue-arbitrage">
    Surface arb spreads to users across venues.
  </Card>

  <Card title="Portfolio monitor" icon="chart-pie" href="/start-here/cookbook/portfolio-monitor">
    Positions + P\&L + live updates. Same patterns power most prediction-market UIs.
  </Card>
</CardGroup>

***

## What you should read next

<CardGroup cols={2}>
  <Card title="Execution overview" icon="cube" href="/execution/overview">
    Full map of the Trading API surface.
  </Card>

  <Card title="Funding & withdrawals" icon="wallet" href="/trading-api/guides/funding-and-withdrawals">
    Every funding path, per venue, including cross-chain bridging.
  </Card>

  <Card title="Best Practices" icon="shield-check" href="/start-here/best-practices">
    Retries, idempotency, rate limits, error handling.
  </Card>
</CardGroup>