A prediction market API gives a program the markets, contracts and order book of an exchange where people trade on outcomes. Each contract pays a fixed amount, usually $1, if the outcome happens. Its price, between $0 and $1, is the market's current estimate of the chance. You read the best bid and the best ask, the depth behind them, and sometimes recent trades.
That makes it a different kind of data from a sportsbook feed. A sportsbook quotes one price per side and builds its margin into both. An exchange quotes two prices per contract, set by other traders, and charges its cost through the spread and fees. If you're building a model, a screen or a bot that reads both, the work is in making those two shapes comparable without fooling yourself.
What you get from a prediction market API
The details belong to each venue's own documentation, but the pieces are similar everywhere:
| Piece | What it tells you | What to watch |
|---|---|---|
| Market or event list | What's tradable, with ids, titles and close times | Ids are the venue's own. They won't match a sportsbook's game ids. |
| Contracts | The outcomes inside a market, such as "yes" and "no" | A multi-outcome market can have many contracts that add up to about $1. |
| Best bid and ask | What you'd get selling now, and pay buying now | The midpoint is not a price anyone will give you. |
| Order book depth | How many contracts sit at each price | The best ask may cover only a few contracts. |
| Trades | What last changed hands, and when | A last trade is history, not a current offer. |
| Streaming | Changes pushed as they happen | Needs reconnection and gap handling on your side. |
Venues differ on authentication, rate limits, fees, who may trade and what you may do with the data. Read those on the venue's own site, every time, because they change.
The two venues developers ask about most
Kalshi is a US exchange for event contracts with its own developer interfaces. Our Kalshi API guide covers what to read first. If you'd rather stream than poll, the Kalshi WebSocket API guide covers subscriptions and reconnection, and the Kalshi Python SDK guide covers using a client library instead of writing raw requests.
Polymarket runs a central limit order book and publishes its own developer documentation. The Polymarket API guide covers where those docs live, how to treat keys, and how to convert a contract price to odds. For reading depth level by level, see the guide to the Polymarket order book API.
ZippyOddsAPI is independent and not affiliated with either.
Converting between contracts and odds
The probability is the price. The odds take one more step.
| Contract ask | Implied chance | American | Decimal |
|---|---|---|---|
| $0.25 | 25% | +300 | 4.000 |
| $0.40 | 40% | +150 | 2.500 |
| $0.50 | 50% | +100 | 2.000 |
| $0.62 | 62% | -163 | 1.613 |
| $0.80 | 80% | -400 | 1.250 |
The rule: at a chance p of 0.5 or more, American odds are -(p / (1 - p)) * 100. Below 0.5 they're +((1 - p) / p) * 100. Decimal odds are 1 / p in both cases. Check one backwards: +150 implies 100 / 250, which is 40%.
These are prices before fees. If the venue charges on a trade, add that cost to the ask first, then convert.
A worked comparison with a sportsbook
Say a sportsbook has a game at -130 for the favorite and +110 for the underdog, and an exchange has the favorite's "yes" contract at a best ask of $0.52.
Step 1: take the margin out of the sportsbook price.
| Side | Price | Implied chance | No-vig chance |
|---|---|---|---|
| Favorite | -130 | 56.52% | 54.27% |
| Underdog | +110 | 47.62% | 45.73% |
The two implied chances add up to 104.14%. Dividing each by 1.0414 removes the margin.
Step 2: compare. The contract costs $0.52 and pays $1, so it implies 52%. If 54.27% is right, each contract is worth about $0.5427, and you pay $0.52. That's about $0.0227 of expected value per contract, or about 4.4% of what you paid.
Step 3: be suspicious of it. That figure is before fees, it assumes the best ask has enough contracts for your size, and it trusts one sportsbook's line as the fair chance. One book's no-vig line is a weak estimate. A consensus of sharp books is a better one, and even that is an estimate. The figure also assumes both prices were read at the same moment. If they weren't, you may be comparing a fresh exchange price with a sportsbook number that has already moved.
A real edge of this size still loses on almost half of all trades. It only shows up as an average over many of them, so size each one with money you can afford to lose.
Matching an exchange market to a game
The hardest part of reading a prediction market API alongside sportsbook data isn't the arithmetic. It's being sure two listings are the same event and the same outcome.
- Match on more than names. Use the start time, both teams and the exact outcome. "Yes" on one contract can mean the home side, the away side or something else entirely.
- Check the settlement rule. Does the contract include overtime? Does a postponement void it or roll it over? A sportsbook moneyline and an exchange contract can look identical and settle differently.
- Err towards no match. A false match creates a fake edge, and a fake edge is worse than a missing one.
Keeping the clocks straight
Every price you store should carry the time it was observed. An exchange's order book can change many times a minute, and a sportsbook's line can sit still for an hour and then jump. When you compare the two, compare observations from close together, and keep a record of how far apart they were.
The same goes for trades. A trade at $0.55 ten minutes ago tells you where the market was, not where it is.
Where ZippyOddsAPI fits
ZippyOddsAPI reads sportsbooks and exchanges from each operator's own public data, keeps the time every price was observed, and works out EV on sportsbook and exchange prices from a no-vig consensus of sharp references.
For prediction contracts it has a separate, raw channel: /v1/prediction-contracts returns stored Polymarket US contract catalog rows and best-bid/offer observations, as the docs describe. Those rows are marked raw_only: true, scoring_eligible: false and execution_eligible: false, with ev set to null. ZippyOddsAPI doesn't merge them into game prices or score them, so the matching and settlement checks above stay your job. A request costs 2 credits and needs the futures feature.
curl -s "https://zippyoddsapi.com/v1/prediction-contracts?source=polymarket_us&kind=contract,bbo&limit=100" \
-H "Authorization: Bearer $ZIPPYODDS_KEY"The API docs list every field, including how the receipt and storage times differ from a native quote time, and how to ask the operator for a key. For a venue's full order book or for trading, use that venue's own API under its own terms.