// PREDICTION-MARKET APIS · PILLAR GUIDE

The complete guide to prediction market APIs (Kalshi + Polymarket)

2026-07-16 · Mithril

If you want to trade prediction markets programmatically in 2026, you are realistically integrating two venues: Kalshi, the CFTC-regulated US exchange, and Polymarket, the largest crypto-settled prediction market. They list overlapping events but expose completely different APIs, auth models, and fee structures. This guide is the map: what each API looks like, where they differ, and what an integration actually involves.

The two venues at a glance

The most important architectural difference: Kalshi looks like a classic exchange API (create key, sign requests, POST orders), while Polymarket is a central limit order book settled on-chain — your orders are typed-data messages signed by a wallet key, and fills settle to USDC on Polygon.

Kalshi's API in five minutes

Kalshi's trade API lives at api.elections.kalshi.com/trade-api/v2. You authenticate by generating an API key in your account settings and signing each request. The core resources:

• GET /markets — list markets, filterable by ticker, event, series, or status. Prices are integers in cents.
• GET /markets/{ticker}/orderbook — the live book.
• POST /portfolio/orders — place a limit or market order on the yes or no side.
• WebSocket channels for the order book, tickers, and your own fills.

A minimal order looks like:

{
  "ticker": "FED-26SEP-T4.00",
  "action": "buy",
  "side": "yes",
  "type": "limit",
  "count": 100,
  "yes_price": 42
}

Two things surprise developers coming from crypto exchanges. First, the fee is a formula, not a flat rate: Kalshi's standard taker fee is 0.07 × contracts × price × (1 − price) (price in dollars), rounded up to the next cent — it peaks at 50¢ markets and shrinks toward the tails. Second, resting orders that provide liquidity generally pay no trading fee on most markets, which changes how aggressive your order placement should be. The full breakdown is in our Kalshi fees explained post, or try the numbers yourself in the Kalshi fee calculator.

Polymarket's CLOB in five minutes

Polymarket splits its API across two services. Gamma (gamma-api.polymarket.com) serves market metadata and prices — no auth required, great for research. The CLOB API (clob.polymarket.com) handles orders, and this is where the crypto machinery lives:

1. Every market outcome is an ERC-1155 token with a token_id; a market is identified by its condition_id.
2. You authenticate in two layers: your wallet key (L1) derives API credentials (L2) used for REST calls.
3. Orders are EIP-712 typed-data messages signed by your key, submitted to the operator, matched off-chain, and settled on-chain on Polygon.

The official py-clob-client hides most of this:

from py_clob_client.client import ClobClient

client = ClobClient(host, key=PRIVATE_KEY, chain_id=137)
client.set_api_creds(client.create_or_derive_api_creds())

order = client.create_order(OrderArgs(
    token_id=YES_TOKEN_ID,
    price=0.42,
    size=250,
    side="BUY",
))
client.post_order(order)

Polymarket charges no exchange trading fee on most markets today, but that does not make execution free: the spread, price impact in thin books, and Polygon gas on settlement are the real costs. More in Polymarket fees and gas explained.

Where integrations actually hurt

Having built against both, the pain concentrates in four places:

• Two ID schemes. Kalshi tickers (FED-26SEP-T4.00) vs Polymarket condition IDs (0x26d06d9c...). Matching the same real-world event across venues is manual work — there is no shared identifier. This is why unified market IDs matter.
• Two auth models. API-key request signing vs wallet-derived credentials and EIP-712 orders. Your key-management story is completely different per venue — see agent custody for why this matters even more once bots hold the keys.
• Two fee models. A formula-based taker fee vs a spread-and-gas cost model. Comparing displayed prices across venues without fee adjustment gives the wrong answer routinely — the displayed-cheaper venue is often the net-more-expensive one. That comparison is exactly what smart order routing does on every order.
• Different failure semantics. Rate limits, order lifecycle states, and error codes don't line up; retry logic written for one venue double-fires on the other unless you build idempotency yourself.

The build-vs-buy question

A single-venue read-only bot is a weekend project. A production system that trades both venues — with fee-aware routing, unified IDs, risk caps, and sane retries — is a multi-month build that you then maintain forever as both APIs evolve.

That maintenance burden is the reason Mithril exists: one REST API and a hosted MCP server that fronts both venues with unified mkt_ IDs, fee-aware routing, and hard server-side risk limits. Whether you build or buy, the rest of this pillar covers what you'll need either way:

• Kalshi API guide: your first order
• Polymarket CLOB API guide
• Kalshi API vs Polymarket API: the differences that bite
• Build a prediction-market trading bot in Python
• Rate limits, order types, and websockets

APIs change. Details above reflect public documentation as of July 2026 — always confirm against the venues' own docs before trading real money.