For developers and platform teams
Prediction market API for sportsbooks, casinos and fintechs
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.
- 41
- Partner API paths
- 48
- 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. The whole division of work between an operator and its supplier is set out in what a B2B prediction market provider should own.
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
Questions
What integration teams ask about the API.
How long does a prediction market API integration take?
It is five calls in the order you write them: list the catalogue, take a quote, submit the order against it, read the position, then receive settlement by webhook. A TypeScript client wraps them with paging helpers, per-user scoping and typed errors, and the sandbox can be driven to outcomes that have not happened yet, so the settlement path is tested before launch rather than after.
Do I have to build my own front end?
No. The same account can render the embedded surface instead, where Parity draws the market list, the ticket and the positions and your page hosts them. The API is for teams that would rather render the product themselves.
How is the API priced?
Per integration. Your rate is set by the volume you run through it and by what you take: the normalised catalogue, quotes and execution, positions and settlement, the embedded surface and the five-minute crypto markets. Talk to us and we will put a number against your integration.
How does settlement work through the API?
A resolved event becomes a settlement record, decided on the published resolution rules attached to the contract. It is delivered to your webhook endpoint signed and retried, and it is safe to apply twice without paying a customer twice. Two reconciliation endpoints, a point-in-time statement and an append-only feed, let you check your books against ours.
Who holds customer funds, and what about licensing?
You do. Parity never holds your customer funds and never authenticates your end users; your ledger stays the single authoritative record of their cash. Your licence, KYC and jurisdictional footprint stay yours too. Where the final allocation of regulatory responsibility falls is a commercial and legal question per jurisdiction, and we will tell you what is available against the licence you hold.
Which markets does the API return?
A normalised catalogue: each event is one question with an ordered set of priced outcomes and a canonical category rather than a venue tag. Offering rules set per operator decide which categories your keys can list, quote and trade, and they are enforced on all three.
Can the API power a white label product?
Yes. Prices, positions and settlement records come back as data, so everything your customers see is rendered by you and carries your brand alone. If you would rather not build the interface, the embedded surface takes your accent colour, mode, radius and density instead.
Read next
For sportsbooks
Prediction market platform for sportsbooks
How prediction markets sit beside a book: who prices, who holds the risk, and what settles it.
Read moreFor casinos
Prediction market platform for online casinos
New wagering inventory on the wallet, brand and licence a casino already has.
Read moreWhite label
White label prediction markets
The embedded surface in your brand, for teams that would rather not build the front end.
Read moreIntegration
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.