Introduction

Symbiosis is a block-execution venue for prediction markets. The REST API covers three services behind one hostname:

Auth

Accounts, sessions, API keys, and websocket tickets.

Custody

Deposit addresses, balances, and withdrawals.

RFQ

Quote requests, quotes, and matching.

Core concepts

Requests and quotes. A taker posts a quote request for an asset on a venue (Polymarket, Kalshi, or Limitless). Market makers see the request (without the requester’s identity, unless the requester opted into disclosure) and respond with quotes. The taker accepts a quote to match. Quotes expire; a match against an expired quote is rejected. Custody. Deposits arrive on per-user derived addresses. Balances are tracked per (venue, asset), with USDC held separately. Withdrawals are queued and processed asynchronously.

Wire formats

Type	Format
Token amounts (`U256`)	Responses: `0x`-prefixed hex strings. Requests: decimal strings, `0x`-hex strings, or JSON numbers.
Asset ids, addresses	`0x`-prefixed hex strings.
Prices	Integers scaled by 1e6 (`650000` = 0.65).
Ids (users, requests, quotes, orders)	UUIDs.
Timestamps	RFC 3339 / ISO 8601.

Identifiers and uniqueness

For integrators mirroring this API into their own storage:

Guarantee	Identifiers
Globally unique, never reused	`user_id`, `api_key_id`, `request_id`, `quote_id`, `match_id`, `withdrawal_id`, `job_id`, audit event `id`. The ledger’s `entry_id` is also strictly increasing: a safe dedupe key and cursor.
Unique per user	`client_withdrawal_id`, the caller-chosen idempotency key. Replaying the same id and terms returns the original withdrawal; the same id with different terms returns `409`.
Composite keys	An outcome token is `(venue, asset_id)`, never `asset_id` alone. Balances are keyed by `(user, venue, asset_id)`, with USDC held separately.
Not unique	A ledger `ref_id`: every entry the same record caused shares it (a match writes an asset leg, a USDC leg, and a fee entry). A withdrawal’s `transaction_hash`: it can change if the job is re-signed, so key on `job_id`.

Request ids

Every response carries an x-request-id header: a server-minted UUID that keys our logs. Include it when reporting a problem. The server never adopts an id you send; an inbound x-request-id is logged alongside ours, so if you attach your own ids, a request that never got a response can still be found.

Websockets

Market data, user events, and the RFQ stream are served over websockets (/ws/market, /ws/user, /ws/rfq), authenticated with short-lived tickets minted from POST /auth/ws-ticket. The protocol (tickets, handshakes, and event frames) is documented in Websockets.

Getting started

Integration guide

Auth

Custody

RFQ

Core concepts

Wire formats

Identifiers and uniqueness

Request ids

Websockets

Auth

Custody

RFQ

​Core concepts

​Wire formats

​Identifiers and uniqueness

​Request ids

​Websockets

Core concepts

Wire formats

Identifiers and uniqueness

Request ids

Websockets