Prediction market APIs: what you actually need to integrate

Endpoint lists are the easy half of an integration and the half that tells you least. Two APIs can expose the same six resources and differ completely in whether you can finish against them. What matters is a smaller set of guarantees: what a price means, what a retry does, and who is authoritative about money.

A catalogue you can actually model against

The first thing an integration needs is one shape for a market, regardless of which venue it came from. That means a stable identifier, an outcome model that does not change meaning between venues, and a status that tells you whether the thing is tradeable right now, rather than merely whether it exists.

That last distinction is worth pausing on, because it is a common source of quiet bugs: a filter that means tradeable is repeatedly read as meaning real. A market can exist, be perfectly valid, and still not be something you may take a wager on this second.

Indicative price and executable price are different fields

Every prediction-market API will give you a number that looks like a price. It is usually a reference: a midpoint, a last trade, or the venue's own stated probability. It is the right number to put on a card. It is the wrong number to charge somebody.

An executable price is what the book will actually fill at, for the side and the size you are asking about, right now. The two can diverge sharply, and they diverge most in fast-moving or near-certain markets, which is exactly when it matters most. An integration should be able to tell, from the payload alone, which kind of number it is holding.

If an API cannot tell you whether a price is indicative or executable, your product will eventually show one and charge the other.

Quotes as a contract, and orders as an idempotent act

A quote should be a commitment with an expiry: this price, this size, this long. That gives your interface something honest to render at the moment of decision, and gives the execution layer something to protect against: a limit beyond which the order does not fill.

Orders need idempotency that you control. If your request times out, you must be able to retry with the same client-supplied identifier and be certain you did not place a second wager. Any API that leaves that ambiguous is one that will eventually double a customer's bet during a network blip.

Positions, settlement, reconciliation

A position has an entry price that never changes and a current mark that changes constantly. Those must be separate fields and must be presented separately, or the customer will believe the market has rewritten what they paid.

Settlement should be driven by the venue's published outcome rather than derived locally, and it should be reconcilable afterwards. You want to be able to answer "why did this position pay what it paid" from records, months later.

The Parity API is built around those guarantees, and the embedded surface is the version where you do not integrate the trading UI at all.