Reference

Going live

What has to be true before this integration carries a real player’s money: on your side, and on ours.

Where this build actually stands

Environment sandboxExecution simulatedTreasury testCustomer custody not approved

This is not a production-approved platform

Prices are live. Fills are produced locally. The treasury is a test wallet. No part of this build is approved to take custody of a member of the public's funds, and no page in this documentation constitutes such an approval.

Stated without hedging: this build is not ready for a live money test of any size, including a nominal one. The order path is production-shaped — a real venue book, a correctly constructed and signed order — and transmission is deliberately unreachable, so nothing it builds can be sent. What does not exist is the other half: nothing reads real fills back, and nothing claims winnings after a market resolves.

Custody structure, the regulatory perimeter, licensing, and the allocation of KYC and AML responsibility between you and Predicta are settled commercially per deployment, with people, before launch. They are not settled by an API contract.

Predicta holds no player funds, and that does not change at launch

You own your customers' cash ledger. Predicta returns exact instructions against it — authorizationAmount, actualDebit, releaseAmount, sellProceeds, settlementCredit, voidCredit — and never a balance of theirs. The sandbox-only balance, ledger and funding endpoints exist so somebody learning the flow has simulated money to spend; they are not the production integration path, and they refuse a live tenant with 403 sandbox_only rather than returning a figure that invites the misreading.

Your checklist

Pricing and display

Tickets render the quote's executionPrice. No surface anywhere renders a reference probability as a price.
Where no executable price is published, the surface shows no price and the controls are disabled. It never falls back to the reference.
priceBasis is read. A reference-basis quote is displayed as an estimate or not displayed at all.
Prices are carried at the precision received. No rounding to whole cents anywhere in the path from response to display.

Money

Your ledger acts on operatorMoney and operatorExitMoney, never on the float fields beside them. Amounts are parsed as decimal strings and never through a float.
Both identities are asserted before posting: authorizationAmount = actualDebit + releaseAmount and actualDebit = tradeAmount + platformFee + venueFee. Exactly, not to a tolerance.
A partial fill releases a non-zero releaseAmount, and your code releases it. Debiting the full stake keeps money that is not yours to keep.
A sell credits sellProceeds and never debits. Nothing in your code path treats a null operatorMoney as a reason to fall back to the entry shape.
The stake is reserved on your wallet before the quote, not after the order.

Orders and recovery

Every order carries a clientOrderId derived from the reservation in your own ledger, and every retry reuses it.
409 reconciliation_required holds the authorization and polls. No branch anywhere releases on it, and no branch re-quotes on it.
The recovery path is exercised: kill the process mid-order and find the order again with GET /api/v1/orders?externalUserId=&clientOrderId=.
settlementState is what your wallet switches on, not status.
409 re-quotes and re-confirms with the player. 422 never retries unchanged.
partially_filled is handled. filledQuantity, not the quote's contracts, is what the player holds.

Settlement and operations

The settlement consumer keys on the settlement id or positionId, advances its cursor only after a successful credit, and is safe to run twice.
A void is credited from voidCredit, including the fee, and a full settlement cycle including a void has been run end to end.
A nightly close reads GET /api/v1/reconciliation and alerts on any critical finding.
simulated is read and surfaced somewhere your operations team can see it.
Backoff with jitter exists for 429 and 5xx, and RateLimit-Remaining is read on successful responses.
Keys are stored in a secret manager and the rotation path has been rehearsed.
Scopes are narrowed per credential. A read-only integration key does not carry orders:write.

What has to be true on Predicta’s side first

Stated plainly, because a partner discovers all of it in one technical call anyway. Each of these is a gate, not a roadmap item.

Gate	State today
Live execution against a real book	Deliberately unreachable. Quotes read the venue’s real order book, and three independent gates must clear before anything is transmitted — one of them a hard-coded literal, so enabling it is a reviewed source change rather than a configuration toggle.
Order construction and signing	Built and exercised in dry run. The order struct, EIP-712 domain and signature match the venue’s own client, and builder attribution is carried in the signed order. No funded key exists: signing keys are generated in process, and none has ever been used against a real venue.
Reading real fills back, and claiming winnings after resolution	Not built, and the larger of the two gaps. An order that could be sent still could not be reconciled or redeemed.
Webhook delivery switched on	Sender ready, with an encrypted signing keyring that can be rotated without stranding existing endpoint secrets. No destination is configured yet, which is a declared state rather than an outage.
Custody approval and a treasury that is not a test wallet	Not obtained. The funding path targets a test treasury wallet, and this build takes no custody of customer funds.
Cross-source routing equivalence verified by a human, if best execution is ever claimed	Not verified. Do not claim it.
Trading: quotes, orders, idempotency, recovery	Live. Real expiry, real idempotency index, real order state machine, reconciliation-safe reads.
Positions and exits	Live. Positions are readable while open, and a sell sized in contracts closes one out.
The settlement register and reconciliation surface	Live. Filterable, keyset-paged, with the credit computed once on our side.
Rate limiting and scope enforcement across the partner API	Live on every /api/v1 route, applied by one shared gate. Scope is checked before the limit is consumed.
Ledger, balance and funding endpoints	Sandbox-only by design, not unbuilt. They model a Predicta-held balance, which is the wrong model for a live operator; a live tenant gets 403 sandbox_only.

A sensible sequence

The integration order that fails cheapest: build against the sandbox until every failure mode on the errors page has been deliberately triggered and handled — including killing your own process mid-order and recovering it by clientOrderId; run a settlement consumer against real resolutions for a full cycle, including a void; reconcile a period and prove it balances; then hold a commercial conversation about custody and execution before writing a single line that moves a real player's money.

The sandbox is not a lesser environment

It is the same pipeline, the same tables and the same code, with the fill produced locally and the tenant flagged. Everything you prove there about idempotency, recovery, settlement and error handling transfers unchanged.