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 is migrating from integer cents to fixed-point dollar strings, trading now runs on sharded matching engines, and 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, authentication, historical candlesticks, WebSocket streaming, the SDKs, rate limits, and the 2026 changes integrators need to know. Everything here was verified against Kalshi's official documentation as of 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, unique among prediction market venues, 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 Market Data, No Key Needed

The best-kept secret for beginners: Kalshi's public REST market data requires no authentication at all. The quickstart endpoints for series, events, markets, order books, and trades all work with a plain HTTP request:

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

Three things to know as you explore. Pagination is cursor-based: pass cursor and limit (default 100, up to 1000 on trades), and keep requesting until the returned cursor is empty. The order book returns bids only, because in a binary market a YES bid at price X is the same thing as a NO ask at $1.00 minus X; asks are implied, not listed. And prices arrive in two coexisting formats, which brings us to the biggest 2026 change.

The fixed-point migration. Kalshi historically quoted prices as integer cents from 1 to 99. The API now emits parallel *_dollars fields as fixed-point strings with up to four decimal places (for example "0.1200"), which enables subpenny pricing, plus *_fp fields for fractional contract counts. The cent fields still exist, but new code should read the dollar-string fields. The YES plus NO equals $1.00 identity still holds; it just has more decimal places now.

Authentication: API Keys and Signed Requests

For trading, portfolio endpoints, and all WebSocket access, Kalshi uses an API key with per-request signatures. You create a key in your account's profile settings and receive a key ID plus an RSA private key in PEM format, shown once and never stored server-side.

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 full demo environment with mock funds at demo.kalshi.co, with its own REST and WebSocket URLs and separate credentials. It is the right place to test order logic, with the caveat that demo prices do not reflect real markets.

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: live endpoints only cover a rolling window of roughly the last three months. Older data moves behind a dedicated /historical/ namespace with its own market, trade, fill, order, and candlestick endpoints. The boundary is dynamic, so the correct pattern is to call GET /historical/cutoff first, read the cutoff timestamps, and route your queries to the live or historical endpoints accordingly. Build the cutoff check into any backtesting pipeline from day one.

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 every 10 seconds; respond or get disconnected.

Official SDKs

The 2026 SDK lineup, and a naming trap. The current official Python packages are kalshi-python-sync and kalshi-python-async; the older kalshi-python package is deprecated. The trap: you install kalshi-python-sync but import kalshi_python. TypeScript users get kalshi-typescript on npm. Both track version 3.26.0 as of late July 2026, and the Python SDKs require Python 3.13 or newer.

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()

For production systems, the docs point to the OpenAPI spec at docs.kalshi.com/openapi.yaml as the authoritative reference, and an AsyncAPI spec exists for the WebSocket surface.

The FIX API

Kalshi is the only major prediction market venue offering FIX connectivity: FIXT.1.1 transport with FIX 5.0 SP2, covering order entry, market data, drop copy, RFQs, and settlement reports over TLS. Basic connectivity is documented publicly, but order entry with retransmission, RFQ creation, and settlement reports require institutional approval through Kalshi's institutional team. If your firm already runs FIX infrastructure, this is the shortest path from traditional markets into event contracts.

Rate Limits and Tiers

Rate limiting is token-based, not request-based: most authenticated calls cost 10 tokens against separate read and write buckets, shared between REST and FIX. The default Basic tier allows 200 read and 100 write tokens per second, a free self-serve upgrade to Advanced roughly triples that, and higher tiers up to thousands of tokens per second are earned automatically through 30-day trading volume. Exceeding a bucket returns a 429 with no penalty beyond the rejection, and per-endpoint costs are queryable through the API itself.

What Else Changed in 2026

Three more changes worth knowing before you build. Exchange sharding: trading now runs on category-based matching engines, collateral must be pre-allocated per shard, and orders carry an exchange_index parameter, with -1 auto-routing by market; naive bots that assume one pool of collateral will break. Perpetual futures: a separate margin API family (REST, WebSocket, and FIX) now exists alongside the event-contract API. Subaccounts and order groups: available from the Advanced tier up, useful for strategy isolation, with the caveat that order groups do not span shards.

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, they cost nothing and teach the market structure. Move to the demo environment before risking capital, get the two signature details right (milliseconds, no query params), read dollar strings instead of cents, and check the historical cutoff before assuming data exists. Do those five things and the integration is genuinely smooth.

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.