The Kalshi API: market data, API keys, rate limits and the demo

The older host api.elections.kalshi.com still works. Kalshi notes that, “despite the elections subdomain, the production Trade API provides access to all Kalshi markets” (Kalshi, API environments). WebSocket connections need a key even for public channels: they “require authentication during the connection handshake” (WebSocket quick start). FIX access comes by default to “members on the Premier tier or above” (Kalshi FIX docs).

Kalshi says it “provides several public endpoints that don’t require API keys” (market data quick start). Its data is organised in three levels. A market is a single yes/no contract. An event is “a collection of markets”, and a series is “a collection of related events” (Kalshi, terms). For example, the series KXHIGHNY contains the event KXHIGHNY-24JAN01, which contains the market KXHIGHNY-24JAN01-T60. Kalshi warns developers not to parse tickers to work out those links; read them from the API instead.

• GET /series, /events and /markets: find what is listed, with filters.
• GET /markets/{ticker}/orderbook: the resting orders on one market.
• GET /markets/trades: recent trades.
• GET /series/{series}/markets/{ticker}/candlesticks: price history in 1-minute, 1-hour or 1-day bars.
• GET /exchange/status: whether the exchange is open for trading.

Two details trip up new users. First, the order book returns yes bids and no bids only, with no asks: “a yes bid at 7¢ is the same as a no ask at 93¢” (orderbook endpoint). Our bid vs ask lesson explains the mirror. Second, prices are no longer whole cents. They are “fixed-point dollar strings … up to 4 decimal places”, because some markets now tick in fractions of a cent (fixed-point migration).

You create a key in your Kalshi account settings, in the API Keys section. Kalshi describes its keys as “asymmetric key pairs: you sign each request with the private key, and Kalshi verifies the signature with the registered public key” (Kalshi, API keys). Ed25519 is the recommended default. RSA (2048-bit, RSA-PSS with SHA-256) is there for clients that support only RSA.

• Every authenticated request carries three headers: KALSHI-ACCESS-KEY (the key ID), KALSHI-ACCESS-TIMESTAMP (in milliseconds) and KALSHI-ACCESS-SIGNATURE.
• The signature covers the timestamp, the HTTP method and the path (such as /trade-api/v2/portfolio/orders), without the host or the query string.
• Kalshi shows the private key once: it “will not be stored by our service, and you will not be able to retrieve it again once this page is closed.”
• Anyone holding the private key can trade your account. Keep it out of code repositories, shared notebooks and chat messages.

Orders go to POST /portfolio/events/orders, Kalshi’s V2 order endpoint. It uses a “single-book bid/ask side and fixed-point dollar prices” (create order V2). In that book, “bid ≡ yes, ask ≡ no, always” (order direction). Buying YES and selling NO are the same position, and so are buying NO and selling YES. An order names the market ticker, the side, a count, a price such as "0.4200" and a time in force, and it can carry your own client order ID so you can track it.

The authenticated portfolio endpoints return your balance, positions, fills, orders and settlements. Kalshi still documents the older /portfolio/orders endpoint, with buy/sell and yes/no fields, as legacy; new code should use V2.

Limits are budgets of tokens per second, with separate read and write buckets. “Most requests cost the default of 10 tokens.” Going over returns HTTP 429, and Kalshi says “there is no penalty or cooldown” (Kalshi, rate limits). Budgets for prediction markets:

At 10 tokens a request, Basic works out to about 20 reads and 10 writes per second. Advanced needs “at least 1 of the user’s last 100 Predictions orders” to have been placed via the API (upgrade endpoint). The higher tiers depend on your share of exchange volume over the past 30 days. Batch requests do not save tokens.

Kalshi splits its data into live and historical tiers. Settled markets, old trades, candlesticks and your older orders and fills move to /historical/* endpoints once they pass a cutoff, which GET /historical/cutoff reports (Kalshi, historical data). When we checked on 9 November 2026, markets and trades before 10 September 2026 had moved to the historical endpoints. Events and series stay on their usual endpoints. Kalshi does not say how far back the archive goes.

Kalshi runs a separate demo exchange “with mock funds” at demo.kalshi.co, with its own API at external-api.demo.kalshi.co/trade-api/v2 (Kalshi, demo environment). Credentials are not shared, so “demo API keys only work against demo endpoints”. It is the place to debug signing and order logic before real money is involved. Is it the real Kalshi? See is demo.kalshi.co legit.

• Official SDKs: kalshi_python_sync and kalshi_python_async on PyPI, and kalshi-typescript on npm. “The old kalshi-python package is deprecated” (Kalshi, SDKs).
• Kalshi says its SDKs “may lag the API” and treats the OpenAPI spec as the source of truth.
• We found no separate charge for API access in Kalshi’s documentation. Trades placed through the API are subject to Kalshi’s fee schedule; see Kalshi fees.
• Designated market makers who quote both sides consistently “may receive reduced fees” after a review by Kalshi (Kalshi help centre).

Polymarket’s API works differently, with wallet-derived credentials and a separate API for US users. See the Polymarket API, and our Kalshi review for the exchange itself.