Predicta API

Overview

Predicta is embedded prediction-market infrastructure. You keep the customer, the wallet and the brand; Predicta supplies the catalogue, the price, the order record and the settlement instruction.

What you build

An integration is three moving parts. Everything else, normalising the catalogue, deriving prices, holding the quote, recording fills, tracking positions, watching for resolution, sits on Predicta's side of the line.

  • A server-to-server call that asks for a price and, if your player accepts it, submits the order. Your own user id travels on a header; Predicta never authenticates or contacts an end user.
  • A surface to show markets in. Either render from the API or embed the Predicta UI.
  • A settlement consumer. Poll the settlement feed and credit your own winners. Every record is safe to apply twice.
  1. 1API key
  2. 2Identify user
  3. 3List events
  4. 4Quote
  5. 5Order
  6. 6Position
  7. 7Settle

Architecture

The operator's application calls Predicta, which prices, records and routes to a connected liquidity pool.Your platformPlayer identityWallet and balanceKYC and supportPredictaCatalogue and pricingQuote serviceOrder and fill recordPositionsSettlement feedWebhook eventsLiquidity poolMatching andcontract resolutionRESTWebhooksRoutedExecution simulated in this build

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

Execution is simulated in this build

Orders are priced from live upstream books, but the fill is produced by a local execution adapter and every quote, order, fill and settlement row is flagged simulated: true. No order reaches a venue and no money moves.

This is structural rather than a switch: every write path to the venue adapter raises VenueNotEnabledError. There is no order signer, no wallet key management and no submit or cancel path. Live execution is not turned off: it is not built. The record, however, is real: the order, its fill, its fee and its position are written in the shape a live venue will write them, with idempotency and settlement already load-bearing.

The API surface today

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.

Partner paths 18Sandbox-gated 5Execution simulatedCustody of player funds yours
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. Idempotent on your own clientOrderId. A sell quote exits.
GET/api/v1/positionsAPI key
What your players hold, and what it cost. Readable per player or across your book.
GET/api/v1/settlementsAPI key
The settlement register, with the amount to credit already computed.
GET/api/v1/reconciliation/feedAPI key
Every money fact recorded for you, totally ordered and resumable.

That is six of eighteen. 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.

Money, stated plainly

You own your customers’ cash ledger

Predicta never holds a player's funds. Every money-moving response carries the exact amount to apply against your own books — reserve authorizationAmount, debit actualDebit, release releaseAmount, credit sellProceeds on an exit and settlementCredit on a resolution — as exact decimal strings, never as 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.

ConcernWhoWhere
Your player’s spendable balanceYours. Predicta refuses a stake for price and freshness reasons only.The money contract
Crediting winners and refunding voidsYours, from the exact figure on each settlement record.Settlement
Proving the two sets of books agreeBoth. A verdict and a resumable stream of every money fact.Reconciliation
A Predicta-held player balanceSandbox only. A learning aid; 403 in live mode.Ledger (sandbox)

No customer custody

This build holds no customer funds. The funding path targets a test treasury wallet and is not approved for customer custody — see Going live for the full list of what must be true first, on both sides.

Who owns what

YouPredictaLiquidity pool
The customer relationship and the brandCatalogue normalisation across sourcesOrder matching
The wallet, the balance and the cash ledgerReference and execution pricingContract terms
KYC, AML and supportQuote, order and position recordsResolution of the contract
Deciding who may see the verticalFee calculation and settlement instructionsVenue-side settlement

Note

The final allocation of custody and regulatory responsibility depends on the commercial structure agreed for each deployment and on your jurisdiction. It is not a technical decision and this documentation does not settle it.

Start here

The quickstart runs the whole integration — key, events, quote, reserve, order, position, exit, settlement, reconcile — in about ten minutes with real, executable requests. The TypeScript SDK does the same in typed calls, with the money contract checked before you see it.