Parity

Overview

Parity is embedded prediction-market infrastructure. You keep the customer, the wallet and the brand; Parity supplies the catalogue, the price, the order record and the exact money instructions. It ships in two shapes. Pick one before you read further.

Two ways to integrate

	Parity Embed (recommended)	Parity Headless
What you ship	An <iframe> and one server endpoint.	Your own UI over the API and the price stream.
Who draws it	Parity draws the market list, the ticket and the positions.	You do.
Server work	Mint a session; reserve, confirm and release against your ledger.	All of that, plus catalogue, pricing, quoting and position rendering.
Time to first order	Days.	Weeks.
Built for	Casinos, sportsbooks and wallets adding a Predictions tab.	Operators and fintechs that already have a trading UI.
Read	Embed integration	Quickstart

Most operators want Embed. It is the fastest route to a working Predictions tab and it is the surface Parity invests in: the market list, the ticket, the price animations, the positions view and the cashout flow are ours to build and ours to keep current. Headless exists for teams whose UI is the product.

Everything below this line is identical in both.

The money architecture

You own ONE authoritative customer cash ledger

There is no Parity player balance. No Parity deposit screen, no Parity withdrawal screen, and no “transfer to Predictions” step. Not ever. Parity never holds a player's funds and has no route that pays one out.

Every money-moving response instead carries the exact amount to apply against your own books: reserve authorizationAmount, debit actualDebit, release releaseAmount, credit sellProceeds on an exit, settlementCredit on a resolution. Exact decimal strings, never floats.

Apply them; never recompute one. The moment an integration multiplies a price by a quantity there are two answers to one question and only one of them is in our ledger.

Concretely, here is the example worth holding in your head for the rest of these docs. A customer has $100 with you and stakes $25:

Parity quotes it. operatorMoney.authorizationAmount is "25.00".
You reserve $25 in your ledger. The customer sees $75 available, $25 reserved. Their money never moved anywhere.
Parity is told only whether that reserve succeeded. It owns the order from there: routing, fills, positions, cashout, settlement, fees, reconciliation.
If you cannot reserve it, you decline. Parity shows an insufficient-funds state, invents no fill, and transmits nothing to a venue.

Parity owns	Parity never owns
Catalogue, live pricing, quote, order, routing, fills, positions, cashout, settlement, fees, reconciliation, and the exact money instructions.	Player deposits, withdrawals, the general cash balance, the casino wallet, the customer account, KYC, support.

The full contract, including partial fills, exits and the two identities that hold exactly, is on The money contract.

The execution path

Catalogue livePrices liveSettlement liveCustody of player funds yours

An order is recorded before it can execute, and it becomes executable when you confirm that the customer's funds are held. Parity writes the row first on purpose: an execution that succeeds upstream and then fails to be recorded is the one outcome with no recovery path. That ordering is what the reserve handshake exists to express, and it is why reserve_pending and pending_venue_execution are states a partner can read rather than internal detail.

An order is not a fill

executionIntent: "simulate" produces an immediate simulated fill and a simulated position. That is sandbox behaviour, defaulted to only for a tenant that is a declared simulation, and it must never be read as the production order path. Read simulated on the response rather than assuming either. See Sandbox and Going live.

Load-bearing on both paths: the normalised catalogue, live pricing off real upstream books, real quote expiry, the durable order record, idempotency, the reserve handshake, cancellation and release, collateral, settlement records and reconciliation. The state names are the same in the sandbox and live, so an integration built against them does not change when the key does.

Parity does not warehouse event risk. A position is intended to rest against the connected liquidity pool's order book, and Parity monetises the transaction and platform layer through an explicit fee rather than by taking the other side.

The API surface

Two surfaces, deliberately separated. /api/v1/* is the partner API and requires an operator key. /api/* is the public catalogue and the public demo; it takes no credentials because it powers a page anyone can open. Do not integrate against /api/*.

Partner paths 26Operations 31Sandbox-gated 7Spec /openapi.json

Those figures are read from the OpenAPI document at build time, and that document is asserted set-equal to the app router in CI. They cannot describe a surface that is not there.

POST/api/v1/embed-sessionsAPI key

Trade your API key for a short-lived token a browser may hold. The whole of Parity Embed starts here.

GET/api/v1/eventsAPI key

The partner catalogue: one row per question, with its outcomes and executable prices.

POST/api/v1/quotesAPI key

Price a stake on one outcome and hold that price for a fixed window.

POST/api/v1/ordersAPI key

Spend a quote and record the order. Idempotent on your own clientOrderId.

POST/api/v1/orders/{id}/confirm-reserveAPI key

“The customer's funds are held.” The order becomes executable.

POST/api/v1/orders/{id}/cancelAPI key

Withdraw an order that has not reached a venue and receive the exact release instruction.

GET/api/v1/settlementsAPI key

The settlement register, with the amount to credit already computed.

The full list, with parameters and response fields, is in the API reference, which is checked against the route handlers in CI. It cannot list a path that does not serve, and it cannot omit one that does. A machine-readable spec is at /openapi.json, and a typed client is at TypeScript SDK.

Who owns what

You	Parity	Liquidity pool
The customer relationship and the brand	Catalogue normalisation across sources	Order matching
The wallet, the balance and the cash ledger	Reference and execution pricing	Contract terms
KYC, AML and support	Quote, order and position records	Resolution of the contract
Deciding who may see the vertical	Fee calculation and settlement instructions	Venue-side settlement

Note

Custody and regulatory responsibility are allocated by the commercial structure agreed for each deployment and by your jurisdiction. That is a commercial conversation rather than a technical one, and Going live lists what it covers.

Start here

Building a Predictions tab? Parity Embed is the whole integration on one page, with copy-pasteable code.
Building your own UI? The quickstart runs key, events, quote, reserve, order, position, exit, settlement and reconcile in about ten minutes with real, executable requests.
Either way, read The money contract before you write a line that touches a balance.