Every prediction market exchange has its own way of representing data. Market structures, order formats, position tracking — none of it is consistent across platforms. PAPI's job is to make all of that disappear behind a single, clean interface.
The Shape of the Problem
Take something as simple as a market. On Polymarket, a market has a condition_id and tokens array. On Kalshi, it's an event_ticker with nested markets that have yes and no outcomes. The naming, nesting, and semantics are all different.
Now multiply that across every entity — orders, fills, positions, orderbooks — and every exchange. The surface area of inconsistency is enormous.
Our Normalisation Layer
At the core of PAPI is a normalisation layer that maps exchange-specific responses into a unified schema. Every API response you get back from PAPI follows the same structure, regardless of which exchange the data came from.
For markets, we normalise to a common shape:
market_id that encodes the exchange and native IDoutcomes array with standardised fieldsstatus enum across all exchangesvolume and liquidity in USDHandling Edge Cases
The tricky part isn't the happy path — it's the edges. What happens when one exchange supports limit orders but another doesn't? When decimal precision differs? When one exchange uses CLOB and another uses AMM?
We handle this through capability flags on each exchange adapter. Your code can check what's supported before attempting an operation, and PAPI will return clear errors when an operation isn't available on a given exchange.
Why This Matters
Normalisation isn't glamorous, but it's the foundation that makes everything else possible. Without it, every consumer of prediction market data would need to build and maintain their own mapping layer. With PAPI, you write your logic once and it works everywhere.
