Sports prediction market API: Kalshi vs Polymarket

The last trade is not your price

A prediction market can display 50%, quote an ask at 53% and fill a larger order at an average of 54.2%. All three numbers are correct. Only one describes what the full order could cost now.

Kalshi and Polymarket are order books. A buyer takes available asks. A seller takes available bids. The last trade records an earlier transaction, while the midpoint sits between the current bid and ask. Neither proves that enough size is available at that number.

A useful sports prediction market API therefore needs more than a headline probability. It needs the bid and ask ladders, size at each level, fees, freshness and a reliable way to match the contract to the corresponding sports event.

What the normalized contract returns

The prediction-market endpoint keeps the provider identity intact while giving both sources the same response shape. You can filter by provider, market key, contract ID and ladder depth.

Kalshi's official order-book documentation exposes active bid orders for the YES and NO sides; the opposite side can be derived in a binary contract. Polymarket's official order-book response includes bids, asks, size and last trade price. odds-api.net converts the supported sports contracts into one explicit probability-ladder model while retaining the original provider and contract IDs.

Request both order books

Find the sports event first. Then request the dedicated prediction-market snapshot for its event_id. Keep the API key on your server.

curl --request GET \
  --header "X-API-Key: $ODDS_API_KEY" \
  "https://api.odds-api.net/v1/events/{event_id}/prediction-markets/orderbook/snapshot?providers=kalshi,polymarket&depth=5&include_unavailable=true"

{
  "event_id": "{event_id}",
  "items": [
    {
      "provider": "polymarket",
      "provider_market_id": "{provider_market_id}",
      "market_key": "moneyline",
      "source_ts": "{source_timestamp}",
      "contracts": [
        {
          "contract_id": "{contract_id}",
          "outcome": "home",
          "probability_bids": [{"price": 0.51, "size": 80}],
          "probability_asks": [
            {"price": 0.53, "size": 40},
            {"price": 0.55, "size": 60}
          ],
          "best_bid_probability": 0.51,
          "best_ask_probability": 0.53,
          "last_trade_probability": 0.50,
          "gross_decimal_odds": 1.8868,
          "fee_adjusted_decimal_odds": 1.84
        }
      ]
    }
  ],
  "resume": "{resume_token}"
}

Open the live reference for current parameters, response codes and schemas.

Price the order you intend to fill

Assume a buyer wants 100 YES contracts. The visible ladder offers 40 at 0.53 and 60 at 0.55.

The 2.00 last-trade conversion overstates the current executable return. Even the 1.887 top ask applies only to the first 40 contracts. The full order reaches the second level and produces gross decimal odds of 1.845 before fees.

Use fee_adjusted_decimal_odds when it is present. Provider fees can depend on the market and fee model, so a single hard-coded percentage is not a safe substitute.

def executable_buy(asks, contracts):
    remaining = contracts
    cost = 0.0

    for level in sorted(asks, key=lambda row: row["price"]):
        filled = min(remaining, level["size"])
        cost += filled * level["price"]
        remaining -= filled
        if remaining == 0:
            break

    if remaining:
        return None  # not enough displayed size

    average_probability = cost / contracts
    return {
        "contracts": contracts,
        "cost": cost,
        "average_probability": average_probability,
        "gross_decimal_odds": 1 / average_probability,
    }

Compare the same contract with sportsbooks

The shared event_id removes one difficult join. It does not prove that two markets settle identically. Match the outcome, period, line and settlement terms before placing prices in the same row.

Back and lay exchanges use a different order-book model. The betting exchange API covers normalized exchange ladders, while the Betfair API guide documents the exchanges=betfair filter and Betfair-specific fields.

1. Match the event

   Use the same canonical event_id. Do not join on team names alone.

2. Match the contract

   Confirm outcome, period, market type, line and settlement wording.

3. Price the required size

   Walk the ask ladder instead of copying the top ask or last trade.

4. Apply fees

   Compare the returned fee-adjusted prediction price with the available sportsbook odds.

5. Reject stale data

   Use source and observation timestamps. Missing freshness means no comparison.

Snapshot first. Stream the changes.

The REST response gives you a complete starting state and a resume token. Pass that token as since when opening the SSE or WebSocket route.

curl --no-buffer \
  --header "X-API-Key: $ODDS_API_KEY" \
  "https://api.odds-api.net/v1/events/{event_id}/prediction-markets/orderbook/stream?providers=kalshi,polymarket&depth=5&since={resume_token}"

Compare REST, SSE and WebSocket delivery.

Build the comparison with one API account

Direct provider integrations leave your product responsible for event matching, source-specific authentication, response translation, fee handling and stream recovery. odds-api.net keeps the source IDs but gives the supported sports contracts one event-level API shape.

Know the boundary

• The prediction-market routes provide market data. They do not place, cancel or manage trades.
• Supported contracts are limited to prediction markets linked to covered canonical sports events.
• A normalized event link does not override the provider's contract wording or settlement rules.
• Liquidity can change before an order reaches a venue. Displayed size is evidence, not an execution guarantee.
• Access to a market or trading venue depends on the provider's rules and the user's jurisdiction.