Is There One API for All Prediction Markets

It sounds like a plumbing question. It is really a question about how much work you can delete.

Every venue runs its own exchange, its own auth, its own identifiers and its own resolution rules, so writing a client for one teaches you almost nothing about the next. The honest version of "one API for all prediction markets" is not an endpoint owned by the industry. It is a normalization layer that talks to each venue and hands back one shape.

Why is there no single official prediction market API?

Because each venue is a separate exchange and none of them agreed on a format. No governing body publishes a prediction market data standard, so every venue invented its own.

The differences are not cosmetic. Some venues quote in cents on a 1 to 99 scale. Some settle on chain and expect an order signed by a wallet key. Some use decimal odds. Identifiers are venue-local strings that do not exist elsewhere. Two venues can list one event with resolution criteria differing by a single word, and that word decides whether a cross-venue position is a hedge or two unrelated bets.

Five problems per venue. Multiply by the venues you want and you have the reason most teams stop at two.

What does one prediction market API actually unify?

Reads unify almost completely, and writes do not unify at all. That split is the thing to understand before designing around any aggregation layer.

A layer can normalize markets, prices, order books and streams, because those are descriptions of state. It cannot fire one order into several venues at once, because each venue owns its matching engine, custody model and signing rules.

How many prediction markets can you cover with one API key?

With Predictefy, 15+ venues on a single key, which is the widest coverage of any cross-venue scanner. The named list includes Kalshi, Polymarket, Limitless, SX Bet, Novig, ProphetX, PredictIt, Myriad, Opinion, Hyperliquid, Smarkets and Gemini.

The count matters less than what arrives when you call them. One normalized schema replaces a separate integration per venue, so parsing, retries, rate limit handling and identifier mapping get written once. When a venue changes a field, your code does not change with it.

The clients are available in beta, so pin the exact version.

# JavaScript and TypeScript
npm install @predictefy/sdk@1.0.0-beta.3

# Python
pip install predictefy==1.0.0b2

# MCP server for agents, MIT licensed
npx -y @predictefy/mcp@1.0.0-beta.3

How do you pull Kalshi and Polymarket data from one endpoint?

You change one segment of the path and keep everything else identical. That is the point of the layer.

curl -s https://data.predictefy.com/api/kalshi/markets \
  -H "Authorization: Bearer pk_live_..."

curl -s https://data.predictefy.com/api/polymarket/markets \
  -H "Authorization: Bearer pk_live_..."

Can one API place orders on every prediction market?

No, and any tool claiming otherwise is describing something it cannot do. Execution at Predictefy is a separate non-custodial service, and it is per venue by design.

The path shape is /v1/exec/{venue}/orders/... for build, submit, cancel, modify and refresh. Build is unmetered, so quoting a trade costs nothing. Submit, cancel and modify charge credits. Every write carries an Idempotency-Key, which stops a retried request from becoming a second position.

POST /v1/exec/kalshi/orders/build       # unmetered
POST /v1/exec/kalshi/orders/submit      # charges credits, Idempotency-Key required
POST /v1/exec/polymarket/orders/build
POST /v1/exec/polymarket/orders/submit

Three limits are worth stating plainly rather than discovering in production. First, orders cap at 100 USD each and 1,000 USD per key per rolling 24 hours. Second, orders are signed client side and there is no generic server-side signing route, so the service never holds your funds. Third, fetchBalance on the hosted API returns 501 NOT_SUPPORTED, so balances come from the venue itself.

That is a narrower promise than "one API places every trade", and it is the honest one. Two legs on two venues means two fills at two moments, and the gap between them is where a paper edge dies.

Are prediction market API prices accurate?

Only where the book behind the quote is deep enough to back it, which on Kalshi is not most markets. A unified feed that hands you midpoints will hand you midpoints that are not prices.

Predictefy measured 5,000 live Kalshi markets on 2026-09-03 from the public Kalshi API, so anyone can reproduce it without a key. In that sample, 18.1% of live markets had no bid at all: on nearly one in five, the quoted midpoint was not a level anyone would trade at. Median spread on two-sided books was 5.1¢.

Depth is what separates a quote from a price, and it splits by volume.

The pattern by category is just as sharp. The widest books are scalar economic markets: KXUSCPIYEAR at 57¢ and KXFEDFUNDSYEAR at 42¢. The tightest are sports, with KXWC at 0.3¢. A cross-venue "opportunity" on a 57¢ book is a formatting artifact, not a trade.

That is the argument for qualifying candidates against live order books instead of midpoints, which is what the Predictefy arbitrage API does. Midpoints are not asks, spreads eat gaps, and depth, fees and resolution equivalence decide whether a trade exists.

Is there a free prediction market API?

Yes. The Predictefy Free plan costs $0 and includes 25,000 credits a month, 60 requests a minute, 1 API key and 2 WebSocket streams. The arbitrage API is free, so cross-venue comparison is not the thing you pay to unlock.

Only the free tier's quotas are quoted here, because those are the numbers you can test against today without paying. The arbitrage API sits on the free side of that line.

Frequently Asked Questions