Prediction market API
One prediction market API, not one integration per venue.
A normalised catalogue, executable quotes, idempotent orders, marked positions and settlement, all behind a single set of credentials, so the shape of your integration does not change when the liquidity behind it does.
The problem this replaces
Venue-specific integration is the part that never finishes.
Integrating a prediction-market venue directly is not one project. It is a market model that differs per venue, a price feed with its own transport, an order path with its own authentication and its own custody assumptions, a resolution source you have to learn, and a settlement record you have to translate into your own books. Then a second venue arrives and almost none of it is reusable, because the disagreements are in the data model rather than in the endpoints.
Parity is the layer that absorbs that. One catalogue shape, one price meaning, one order record, one settlement record. The venue that ultimately fills an order is an implementation detail on our side of the line rather than a branch in your code.
- 26
- Partner API paths
- 31
- Operations
- 7
- Sandbox-only paths
- 17
- Canonical categories
Counted from the OpenAPI document the service publishes, which a test asserts is set-equal to the running router. Nothing on this line is transcribed.
The quote a user sees is the quote that executes.
Take a price, then submit the order against it. If the price is no longer available the order is rejected rather than filled at something else. The figures in this response are not written for the page. They are computed by the same pricing function the quote service calls, so a fee change moves this sample exactly as it moves a real quote.
Every field in the response is one the API returns, in the shape it returns it. The sample is generated from the product rather than transcribed into the page, so an integrator can read the keys off it and write against them.
Authorization: Bearer sk_live_…
X-Parity-User: your-user-id
{ "marketId": "…", "side": "YES", "stake": 25 }
← 200
{
"quoteId": "qt_…",
"executionPrice": 0.62,
"contracts": 39.8387,
"potentialPayout": 39.83,
"expiresAt": "…",
"simulated": true
}The integration
Five calls, in the order you write them.
- 01
List the catalogue
GET /api/v1/eventsreturns normalised events (one question, its outcomes and their prices) with the venue's own shape already removed. You page it; you do not crawl it. - 02
Take a quote
POST /api/v1/quotesbinds contract, side, stake, price, fee and quantity into one record with an expiry, and tells your ledger the exact amount to reserve. - 03
Submit the order against it
POST /api/v1/ordersis idempotent on your own order id. If the quoted price is gone the order is rejected rather than filled at something else, and a retried submission returns the original record instead of opening a second position. - 04
Read the position
GET /api/v1/positionsreports what each customer holds, marked against the live price, and is the path an exit before resolution is executed through. - 05
Receive settlement, then reconcile it
A resolved event becomes a settlement record delivered to your webhook endpoint: signed, retried, and safe to apply twice without paying a customer twice. Two reconciliation endpoints exist alongside it: a point-in-time statement and an append-only feed.
A TypeScript client wraps all five with paging helpers, per-user scoping and typed errors. See the SDK. If you would rather not build a front end at all, the same account can render an embedded surface instead.
Guarantees
What the interface promises, beyond the endpoint list.
An endpoint list is the easy half of an evaluation and the half that tells you least. These are the properties an integration actually depends on.
- One question, priced outcomes
- Venues disagree about what a market is. Some publish a binary per outcome, some publish one market with many. Parity normalises both into one event with an ordered set of priced outcomes and a canonical category, so your rendering code is written once. There are 17 player-facing categories and none of them is a venue tag.
- The quote is the contract
- An execution price is not a number you saw on a list. It is a record with an expiry, and the order is checked against it. That is what makes “the price the user saw” a testable property rather than a hope about latency.
- Amounts are exact decimal strings
- Every money-moving response carries the exact amounts to reserve, debit, release and credit. Apply them; never recompute one from a price and a quantity. A JSON number cannot carry an exact cent past a certain size, and the moment an integration multiplies its way to a debit the two ledgers stop agreeing by fractions that compound.
- Idempotency is on your identifier
- Not on ours. A retry after a timeout is the normal case in a payments-shaped integration, and the only key that survives a client that never received a response is the one the client generated.
- Errors are typed, and rate limits are stated
- One error envelope with codes an integration is expected to branch on, and three
RateLimit-*headers on every response so a client can back off before it is throttled rather than after.
Boundaries
What the API will not do.
Parity never holds your customer's funds and never authenticates your end users. There is no Parity balance a production integration reads, no Parity withdrawal screen, and no transfer step between your wallet and a prediction wallet. Your ledger stays the single authoritative record of a customer's cash; Parity is told only whether a reserve against it succeeded.
That is a design decision rather than a missing feature, and it is the one thing about the API that does not bend. It is stated in the docs before any endpoint, for the same reason it is stated here before the capability list.
You own one authoritative customer cash ledger. Parity returns the exact amounts to reserve, debit, release and credit against it.
Current state
What runs today, stated first.
Running today
- Continuous ingestion and normalisation from multiple liquidity pools
- Tens of thousands of open contracts, with prices, history and resolution rules
- Quotes, orders, positions, early exit and marks
- Settlement records, webhooks and two reconciliation endpoints
- A sandbox that can be driven to outcomes that have not happened yet
Read next
Integration
Prediction market APIs: what you actually need to integrate
The guarantees an integration depends on, separated from the endpoint list that tells you least.
Read moreArchitecture
Embedded prediction markets: who owns what
The responsibility split in full: users, brand, KYC and balances on one side; market infrastructure on the other.
Read moreCase study
House Money puts prediction markets inside its own casino
One server endpoint, a message listener and an iframe, plus what Parity runs behind the frame.
Read moreRead the docs, or get an account.
The quickstart goes from credentials to a first trade. If you would rather talk through the architecture first, we would rather do that too.