Yes, Kalshi has an API. Kalshi is a regulated US exchange for event contracts, and it publishes API documentation for developers who want to read its markets in code and, with an account, trade them. The Kalshi API is the way to get Kalshi's own prices into a program, and Kalshi's docs are the only reliable source for how it works today.
So the short version is: read Kalshi's documentation first, then build. This guide covers what to look for in those docs, the one piece of arithmetic every Kalshi integration needs, and where it fits next to sportsbook data. Endpoints, authentication, limits and fees change, so none of them are repeated here.
Does Kalshi have an API?
It does, and it's documented publicly. People who ask "does kalshi have an api" usually want one of three things, and it helps to know which before you start reading:
| What you want | What to look for in Kalshi's docs |
|---|---|
| Prices and markets for research or a dashboard | The market data sections, and whether they need a key |
| Live updates without polling | The streaming or WebSocket section |
| Placing and managing orders | Authentication, order and portfolio sections, and the trading terms |
Each of those has its own guide on this site. Streaming is covered in our Kalshi WebSocket API client guide, keys in handling a Kalshi API key, and Python tooling in setting up the Kalshi Python SDK.
What to read first in the Kalshi API docs
Kalshi's docs are long, and it's easy to start at the order endpoint and work backward. A better order:
- The market model. How Kalshi groups events, markets and contracts, and what identifies each. Your database keys come from here.
- Prices and units. Kalshi contracts are priced between 1 and 99 cents and pay out on whether the event happens. Confirm the exact units and fields the docs use before you parse anything.
- Authentication. Which requests need a key, and how requests are signed or authorized.
- Limits. How many requests you can make, and what happens when you go over.
- Fees and terms. What trading costs, and what you may do with the data.
The Kalshi API documentation also says which parts of the service, if any, can be read without logging in. Searches for a "kalshi public api" are usually asking exactly that, and the answer belongs to Kalshi, so check its current docs rather than an old answer online.
From a contract price to a probability
Every Kalshi integration needs the same conversion. A contract that pays $1 if the event happens and costs 40 cents implies a 40% chance, before fees. The rest follows from that:
def contract_to_odds(price_cents: int) -> dict:
if not isinstance(price_cents, int) or not 1 <= price_cents <= 99:
raise ValueError("contract price must be a whole number of cents from 1 to 99")
p = price_cents / 100
if price_cents < 50:
american = round(100 * (100 - price_cents) / price_cents)
else:
american = -round(100 * price_cents / (100 - price_cents))
return {"implied": p, "decimal": round(1 / p, 4), "american": american}
print(contract_to_odds(40)) # {'implied': 0.4, 'decimal': 2.5, 'american': 150}
print(contract_to_odds(62)) # {'implied': 0.62, 'decimal': 1.6129, 'american': -163}Check the second one by hand: at 62 cents you risk 62 to win 38, and 62 / 38 x 100 = 163.2, so -163. At exactly 50 cents the function gives -100, which is the same price as +100.
Two cautions. First, fees come off what you're paid, so the break-even chance is higher than the price suggests. Take the fee rules from the Kalshi documentation and apply them before comparing with anything. Second, a yes and a no on the same contract don't always add to 100 cents at the best bid and ask, just as two sportsbook prices don't add to 100%. The gap is the spread, and using the midpoint as a fair price only makes sense when the book is liquid.
Reading the Kalshi docs as a developer
A few habits make the integration hold up:
- Version your parser. Keep the raw response next to what you parsed from it, so a change in the docs is a one-line fix and not a lost day.
- Keep two clocks. When the price was quoted, and when you received it. A price you read three minutes ago is three minutes old.
- Test in whatever sandbox the docs offer before you send real orders.
- Read the API terms before you redistribute anything. Using data and showing it to others are different permissions.
Kalshi next to sportsbook prices
ZippyOddsAPI is independent and not affiliated with Kalshi. It's a sports odds API that reads each operator's own public data and returns sportsbook, exchange and pick'em prices in one schema, with the time each price was observed. Prediction markets are listed among exchanges, so /v1/sportsbooks?type=exchange shows which ones it knows, and the coverage page shows which are feeding now.
ZippyOddsAPI also has a separate /v1/prediction-contracts endpoint for raw prediction-market contracts and best bid/offer observations. Its documented source today is Polymarket US, not Kalshi. Every row there is marked raw_only: true and execution_eligible: false, with ev: null, because the service doesn't model payout or execution for those contracts. The ZippyOddsAPI docs set out those limits in full.
If you're comparing venues, the Polymarket side is covered in our Polymarket API guide and the more specific piece on keeping a Polymarket order book API feed in sync. For a view across every prediction venue, start with the prediction market API overview.