Prediction market API
for brokers.

01What the API covers

The API is built for brokers acting on behalf of their own clients. Each client maps to an account under your broker ID, and every call is made with your keys. TIE handles matching, collateral, settlement and oracle resolution; your application owns the interface, onboarding and pricing.

• REST under /v1: JSON over HTTPS, cursor-paginated lists, machine-readable error codes.
• WebSocket streams: sequenced frames with resume, so a reconnecting client never misses or double-applies an update.
• Public specs: an OpenAPI document for REST and an AsyncAPI document for streams, plus a versioned changelog with breaking changes flagged. See the API docs.
• Sandbox: a separate environment with seeded balances and the full catalogue, issued within one business day.

02Authentication and idempotency

Requests are signed rather than sent with a bearer token. Each call carries three headers:

• PRE-ACCESS-KEY: your access key identifier.
• PRE-ACCESS-TIMESTAMP: an RFC 3339 timestamp with milliseconds.
• PRE-ACCESS-SIGNATURE: a keyed BLAKE2b-256 signature (64 lowercase hex characters).

The signature covers the method, the path and query, the timestamp, the idempotency key, your broker ID, the access key and a BLAKE2b-256 digest of the request body. It is computed with the secret key paired with the access key, so the secret never travels over the wire.

Every state-changing request (POST, PATCH, DELETE) requires an Idempotency-Key header that stays stable across retries. A network timeout followed by a retry can't create a duplicate order.

WebSocket connections authenticate the same way during the upgrade request. An invalid signature or a timestamp outside the clock-skew tolerance (five minutes by default) is rejected with HTTP 401 or WebSocket close code 4401.

03REST endpoints

04Orders and the order book

Each binary market trades on a single order book for the YES contract. Orders on NO are mapped onto it: buying NO executes as selling YES at 1 − price, so the client's price limit is preserved and liquidity on both sides sits in one book. Net positions are signed: positive means YES held, negative means NO held.

• Order types: LIMIT (price and quantity) and MARKET (a market buy specifies volume to spend; a market sell specifies quantity).
• Time in force: GTC, DAY, IOC (fill what's available, cancel the rest) and FOK (fill everything immediately or nothing).
• Amend and cancel by TIE's order_id or your own client_order_id.
• Pre-trade controls: self-trade prevention, insufficient-funds checks and limits on order quantity, order notional and position size, each returned as a machine-readable status reason.

Matching runs on TIE's proprietary central limit order book with price-time priority. A limit order on behalf of a client looks like this:

# place a limit order on behalf of your client
curl -X POST https://api.tie.tech/v1/trading/accounts/{account_id}/orders \
  -H "Content-Type: application/json" \
  -H "PRE-ACCESS-KEY: $TIE_KEY" \
  -H "PRE-ACCESS-SIGNATURE: $TIE_SIGNATURE" \
  -H "PRE-ACCESS-TIMESTAMP: 2026-08-10T09:42:00.000Z" \
  -H "Idempotency-Key: 8f2c-ab41" \
  -d '{
    "market_id":       "starship-launches-2026-10-or-more",
    "token":           "YES",
    "side":            "BUY",
    "type":            "LIMIT",
    "tif":             "GTC",
    "price":           { "units": 64, "nanos": 0 },
    "qty":             { "units": 250, "nanos": 0 },
    "client_order_id": "cli-ord-8f2c"
  }'

Prices and quantities use a units + nanos decimal format, so there are no floating-point rounding errors.

05Events, markets and settlement

An event is the real-world question; it contains one or more markets, each a YES/NO contract on one outcome or range. "How many Starship launches reach space in 2026?" is one event with a market per range, and several markets of one event can resolve YES.

• Lifecycle: markets move through unopened, pre-open (loaded in the book, so liquidity can be placed before trading starts), active, suspended, closed, settled or voided.
• Recurring series: short-interval crypto markets are tagged with their cadence, from 30 seconds to one day, so you can build a series view in your UI.
• Localised text: titles and rules are returned in English, Portuguese and Indonesian, filterable by language.
• Settlement sources: each event lists the sources used to resolve it, and each market carries its result once the event resolves.
• Payouts: after settlement, the payouts endpoint shows the quantity held, the settlement price and the amount paid per account.

06WebSocket streams

Every data frame carries a monotonic sequence number. After a disconnect, a client reconnects with since= its last applied sequence and the server replays what it missed, for up to one hour. Clients drop any frame with a sequence at or below the last one applied, so delivery is idempotent. Heartbeats keep idle connections alive without advancing the sequence. Full detail is in the WebSocket reference.

07Sandbox and going live

• Sandbox key within one business day, with the full catalogue, seeded balances and a benchmark harness. No contract needed.
• Integrate against the published spec, with an engineer on call.
• Measure: on a single-node benchmark (4-core instance, synthetic flow) the engine matches at 1.2 ms p50 and 8.0 ms p99, sustaining 40,000 orders a second. The harness ships with sandbox access so you can reproduce it with your own key.
• Launch under your brand on the jurisdiction wrapper agreed during scoping.

08FAQ