Kalshi API: The Complete Guide for Developers (2026)

The Kalshi API is the most institution-shaped developer interface in prediction markets: a CFTC-regulated exchange exposing REST, WebSocket, and full FIX connectivity, with USD settlement and official SDKs in Python and TypeScript. It is also, in 2026, an API in motion. Pricing left integer cents behind for fixed-point dollar strings, and the old integer fields were deleted rather than deprecated. Matching is being split across shards. The SDK packages changed names. Tutorials written a year ago will steer you wrong in at least three places.

This guide covers the current API surface end to end: free market data, how to get a Kalshi API key, what the API costs, historical candlesticks, WebSocket streaming, the SDKs, and the rate limit tiers. Every endpoint, field name, and number below was checked against Kalshi's official documentation on 9 August 2026.

What Is the Kalshi API?

Kalshi is a CFTC-regulated US exchange for event contracts: binary markets that pay $1.00 per contract to the winning side. The developer surface has three tiers. The REST API at https://external-api.kalshi.com/trade-api/v2 handles everything from market data to order placement. A WebSocket API streams order books, tickers, trades, and fills. And a full FIX API, which almost no other prediction market venue offers, serves institutions that already speak FIX from traditional markets.

One naming quirk to know immediately: the alternative base URL api.elections.kalshi.com serves all markets, not just elections. The docs recommend the external-api.kalshi.com host, and both work.

Everything is organized in a three-level hierarchy: a series is a collection of related events, an event is a collection of markets, and a market is a single binary contract. Tickers nest accordingly, but the docs explicitly warn against parsing ticker strings to infer relationships; use the API's actual fields.

Getting Started: Free Kalshi Market Data, No Key Needed

The best-kept secret for beginners: most of Kalshi's REST market data requires no authentication at all. Series, events, markets, trades, and candlesticks answer a plain HTTP request with no account, no key, and no headers:

curl "https://external-api.kalshi.com/trade-api/v2/markets?limit=10"

Pagination is cursor-based. Pass cursor and limit (the default is 100 and the maximum is 1000 on both markets and trades), then keep requesting until the returned cursor comes back empty. Nothing else about reading market data is complicated. The two things that catch people out are the order book and the price format.

The order book is the exception to "free and public". GET /markets/{ticker}/orderbook is the one market data endpoint whose spec declares the same three signed headers as trading, so budget an API key for it even if the rest of your reader runs anonymously. Two quirks once you are through the door. The book returns bids only, because in a binary market a YES bid at price X is the same resting order as a NO ask at $1.00 minus X, so asks are implied rather than listed. And the payload key is orderbook_fp, holding yes_dollars and no_dollars, each entry a two-element list of price then quantity. Expect to write best_yes_ask = 1 - best_no_bid on your first afternoon, and expect one of the two sides to be empty fairly often, which is ordinary here rather than a bug.

The fixed-point migration is finished, and it was not gentle. Kalshi historically quoted prices as integer cents from 1 to 99. Those fields are gone. yes_bid, yes_ask, last_price, volume, open_interest and tick_size were removed on 12 March 2026 rather than deprecated, so code that reads them raises KeyError and there is nothing to fall back to. What arrives instead is a *_dollars field per price, a fixed-point decimal string that the spec allows up to six places of precision and that in practice shows up with four ("0.1200"), plus a *_fp field per count, carrying contracts to two decimals. The YES plus NO equals $1.00 identity still holds. It just has more decimal places, and it arrives as text you have to cast before you do arithmetic on it.

Kalshi API Pricing: Is the Kalshi API Free?

Yes, in the sense people usually mean. The Kalshi API has no price attached to it: no subscription, no developer plan, no per-call metering, no separate market data product, and no paid tier you can buy to get more throughput. The tiering that does exist is about how fast you may call, not about billing, and the first step up it is a free self-serve call. Nobody is going to invoice you for reading prices.

What costs money is trading, and the fee lands on the contract rather than the request. Kalshi's taker fee is charged per order and rounded up to the next cent, computed as 0.07 x contracts x price x (1 - price). That shape matters more than the coefficient: the fee peaks at 1.75 cents per contract at the 50 cent midpoint and shrinks toward either end of the range, so cheap longshots are cheap to trade and coin flips are not. Maker fees, where they apply at all, run at a quarter of that and only on designated markets. Cancelling a resting order is free, settlement is free, and ACH moves money both ways at no charge. The S&P 500 and Nasdaq-100 series use roughly half the standard coefficient. Our Kalshi fees breakdown walks the arithmetic with worked examples.

So the honest cost model for a builder is: your servers, plus a fee on every contract your code trades. That second line is the one that kills strategies. A signal worth one cent per contract does not survive a fee that can take 1.75 of them, and no amount of clean integration code fixes that. None of this is financial, tax, or legal advice, and published schedules move, so price your model against Kalshi's current fee schedule rather than any blog post, this one included.

Authentication: How to Get a Kalshi API Key and Sign Requests

For trading, portfolio endpoints, the order book, and all WebSocket access, Kalshi uses an API key with per-request signatures. Getting one takes about a minute:

1. Click your profile icon in the top right of the Kalshi app and open Profile Settings.
2. Find the API Keys section and use Create New API Key.
3. Save the RSA private key it shows you, in PEM format. Kalshi does not store it, and closing that page is final.
4. Copy the Key ID that comes with it. The Key ID travels in a header; the private key never leaves your machine.

Two things worth doing at this point rather than later. Make your first key on a demo account, because a demo key against production fails with a 401 that looks exactly like broken signing code. And if you want a key that cannot reach your main balance, create it against a subaccount, since that restriction is set at creation and cannot be added afterwards.

Every authenticated request carries three headers: KALSHI-ACCESS-KEY (your key ID), KALSHI-ACCESS-TIMESTAMP (milliseconds since epoch), and KALSHI-ACCESS-SIGNATURE. The signature is RSA-PSS with SHA-256 over the string timestamp + METHOD + path, and the two mistakes that cause almost every failed integration live right there: the timestamp must be milliseconds, not seconds, and the signed path is the full path from the API root without query parameters.

Kalshi also runs a proper paper trading environment, which most venues do not. The demo exchange lives at demo.kalshi.co with mock funds, reachable at https://external-api.demo.kalshi.co/trade-api/v2 for REST and wss://external-api-ws.demo.kalshi.co/trade-api/ws/v2 for streaming. You need a separate demo account and separate demo keys, because credentials are not shared in either direction. Note the .co, not .com. Kalshi is explicit that demo prices may not reflect real markets, which sets the boundary neatly: paper trading here validates your mechanics, not your edge. It catches signature bugs, reconnect failures, and off-by-one sizing, and it will tell you nothing about whether your rule makes money.

Historical Data and Candlesticks

Candlesticks come from GET /series/{series_ticker}/markets/{ticker}/candlesticks with required start and end timestamps and a period_interval of exactly 1, 60, or 1440 minutes. That is 1-minute, 1-hour, and 1-day candles, and nothing else. A batch variant fetches up to 100 markets per request, and an event-level variant aggregates candles across all markets in an event.

The part most integrators miss: the live endpoints do not hold everything. Older data moves behind a dedicated /historical/ namespace with its own market, trade, fill, order, and candlestick endpoints. At the time of writing that boundary sits somewhere around three months back, but Kalshi publishes no fixed retention number and the cutoff moves, so treat any figure including that one as a guess. The correct pattern is to call GET /historical/cutoff first, which needs no authentication and returns four separate timestamps (settled markets, filled trades, closed orders, settled positions), then route each query to the live or historical endpoint accordingly. Build that check into a backtesting pipeline from day one, because past the boundary the live endpoints hand back HTTP 200 and an empty array rather than an error, and a backtest can quietly train on nothing.

WebSocket Streaming

The production stream lives at wss://external-api-ws.kalshi.com/trade-api/ws/v2. The non-negotiable fact: there is no unauthenticated WebSocket access. Some channels carry only public market data, but the connection handshake itself requires the same three signed headers as REST, signing the literal path /trade-api/ws/v2. This is the exact opposite of REST, where public data needs nothing, and conflating the two is a common integration surprise.

Once connected, you subscribe with a JSON command specifying channels and market tickers. The useful channels for most builders: orderbook_delta for book updates, ticker for price summaries, trade for public trades, and fill for your own executions. The server pings on roughly a ten second cadence at the time of writing; answer it or get dropped, and read the AsyncAPI spec rather than this sentence if you are tuning timeouts.

Official SDKs and the Kalshi API Documentation

The 2026 Python lineup is kalshi-python-sync and kalshi-python-async; the older kalshi-python package on PyPI is the deprecated predecessor and the wrong one to install. Both current packages were at 3.27.0 on 5 August 2026, and both declare Python 3.13 or newer. That last requirement bites harder than it reads: on 3.11 or 3.12, pip does not refuse, it quietly backsolves to a much older release from before the pricing migration, which is a strange and expensive way to spend an evening. TypeScript users get kalshi-typescript on npm.

Then there is the naming trap. Kalshi's own README tells you to pip install kalshi-python-sync and then write from kalshi_python import ..., and that mismatch is deliberate rather than a typo. Builders have also reported the installed wheel exposing kalshi_python_sync, so if the documented import raises ModuleNotFoundError, try the package-shaped name before concluding your install broke. Our Kalshi Python tutorial works through the SDK path properly.

pip install kalshi-python-sync

from kalshi_python import Configuration, KalshiClient

config = Configuration(host="https://api.elections.kalshi.com/trade-api/v2")
with open("path/to/private_key.pem", "r") as f:
    private_key = f.read()
config.api_key_id = "your-api-key-id"
config.private_key_pem = private_key

client = KalshiClient(config)
balance = client.get_balance()

Where the official Kalshi API documentation actually lives. The human-readable reference is docs.kalshi.com, and on field names it is the only source worth trusting, including over this page. Underneath it sit four downloadable machine-readable specs, which are what you should generate clients and validators from rather than hand-typing schemas: openapi.yaml for the REST surface, asyncapi.yaml for WebSocket, and perps_openapi.yaml plus perps_asyncapi.yaml for the margin product. The same site carries a changelog, and after the year this API has had, following it is closer to mandatory than optional. If you point LLM tooling at the docs, docs.kalshi.com/llms.txt indexes every page in one file.

The FIX API

Very few prediction market venues publish a FIX interface at all, and Kalshi's is a real one: FIXT.1.1 transport with application version FIX 5.0 SP2, over TLS 1.2 or higher, with plain TCP refused outright. Six services are offered across production and demo, covering order entry with and without retransmission, market data, drop copy, RFQ quoting, and post-trade settlement reports. Basic connectivity is documented publicly. Retransmission, RFQ creation, and post-trade all need institutional approval, which goes through institutional@kalshi.com. If your firm already runs FIX plumbing, this is the shortest path from traditional markets into event contracts.

This section is also where the answer to the Kalshi server location question sits, such as it is. Kalshi runs on AWS and terminates FIX behind Network Load Balancers, and from the Premier tier upward you can ask for private connectivity over AWS PrivateLink instead of crossing the public internet. What Kalshi does not publish is the region, the availability zones, or any colocation arrangement. So there is no latency number to read off a page and no cross-connect to order. If microseconds decide your strategy, measure from your own host and take the conversation to the institutional team.

Kalshi API Rate Limits and Tiers

Kalshi's rate limits are token-based rather than request-based, which is the first thing to get straight: there is no requests-per-second number to respect. Most calls cost 10 tokens, drawn from two independent buckets that refill continuously at your tier's per-second budget. Writes means order placement, amends, cancels, order groups, the RFQ quote flow, and block trade accepts. Everything else counts as a read. REST and FIX drain the same buckets, so a FIX order session and a REST poller are competing for the same allowance rather than getting one each.

There are seven tiers, and the numbers are published rather than negotiated:

At 10 tokens a call, Basic is roughly 20 reads and 10 writes per second, which is more than most first projects need. The jump to Advanced is the one worth taking straight away: it is free, it is self-serve, and it is a single call to the Upgrade Account API Usage Level endpoint, which takes writes from 100 to 300 and reads from 200 to 300. From Expert upward the tiers stop being something you ask for. Kalshi reviews accounts daily, weighs your trailing 30-day volume against exchange volume, and moves you, and it reserves the right to assign a tier at its own discretion in either direction.

Going over a bucket returns HTTP 429 with a short error body and nothing worse. There is no cooldown, no penalty, and no strike against your account; the bucket keeps refilling and your next attempt succeeds once it has the tokens. Kalshi still recommends exponential backoff, which is the right call for anything running unattended. One detail worth using: per-endpoint token costs are queryable through the API itself, so check the cost of the calls your loop actually makes before you assume every one of them is 10.

What Else Changed in 2026

Three more changes worth knowing before you build. Exchange sharding: markets and series now expose an exchange_index naming the matching engine they live on, and the exchange status endpoint reports health per shard rather than only in aggregate. In practice almost everything still sits on index 0 at the time of writing, so a single-market bot is not affected today. Note it anyway, because collateral is held per engine, and the failure mode is unpleasant to debug: a perfectly healthy total balance and an insufficient-collateral rejection on the one engine you are trading. Perpetual futures: a separate margin product with its own REST, WebSocket, and FIX surfaces, and its own pair of specs, now sits alongside the event-contract API. Subaccounts and order groups: an API key can be scoped to a single subaccount, which is a clean way to isolate a strategy, but only at the moment the key is created. There is no way to add that restriction to a key you already have.

Frequently Asked Questions

Conclusion

The Kalshi API rewards builders who read the current documentation and punishes those working from last year's tutorials. Start with the unauthenticated REST endpoints, which cost nothing and teach you the market structure for free. Move to demo before risking capital. Get the two signature details right, milliseconds and no query params. Cast the dollar strings instead of hunting for cent fields that no longer exist. Check the historical cutoff before assuming a date range is there. Do those five things and the integration is genuinely smooth, which is more than you can say for most exchange APIs.

Where Kalshi fits in the wider landscape, and how its API compares to Polymarket, Limitless, SX Bet, and the multi-venue layers, is covered in our guide to the 7 best prediction market APIs and SDKs in 2026. And if you are new to prediction market APIs entirely, start with our beginner's guide.