What does the Kalshi API provide?
The Kalshi API provides real-time market data and trade execution for event contracts. Kalshi documents three interfaces: REST for requests and account actions, WebSocket for live streams, and FIX for institutional trading workflows. The same documentation also covers perpetual futures, but prediction traders use the event-contract endpoints.
A public REST request can retrieve series, events, markets, and order books without an API key. Kalshi's market data quick start uses the production endpoint at `https://external-api.kalshi.com/trade-api/v2`. Developers can request active markets by series, inspect current prices, and read the order book before creating credentials.
Private actions add more responsibility. Order entry, portfolio data, fills, and positions require authentication. Code that sends orders also needs state tracking, logs, risk controls, and a clean recovery path after a failed request. The endpoint is the easy part. Production trading software owns everything around it.
How do you get a Kalshi API key?
A trader creates a Kalshi API key from the API Keys section in Profile Settings. Kalshi returns a Key ID and an RSA private key. The private key appears once and must be saved immediately because Kalshi does not retain a retrievable copy for the trader.
Each authenticated request carries three headers: `KALSHI-ACCESS-KEY`, `KALSHI-ACCESS-TIMESTAMP`, and `KALSHI-ACCESS-SIGNATURE`. The signature covers the timestamp, HTTP method, and request path. Kalshi tells developers to remove query parameters before signing the path.
Demo and production credentials stay separate. A demo key only works against demo endpoints, and a production key only works against production endpoints. Test the entire order lifecycle in demo before live capital touches the code. A key opens the account. The trader still needs risk controls.
Does the Kalshi API support WebSocket and FIX?
Kalshi supports WebSocket and FIX alongside REST for prediction market data and execution. The production WebSocket host is `wss://external-api-ws.kalshi.com/trade-api/ws/v2`. Kalshi also publishes separate demo hosts, so developers can test streaming behavior without pointing the client at production.
WebSocket fits clients that react to live market updates and account events. REST fits discovery, snapshots, and direct actions. FIX serves trading systems built around the standard institutional protocol. Choosing among them depends on the job. A serious system often uses more than one.
Connection code still has to handle reconnects, stale data, duplicate messages, and state reconciliation. A socket that stays open does not prove the local book is correct. Record sequence state, compare fills against positions, and stop sending orders when the client cannot prove its view is current. Correct state beats a fast mistake.
What are the Kalshi API rate limits?
Kalshi applies token-based rate limits with separate Read and Write budgets. Most authenticated requests cost 10 tokens. Each account tier sets the refill rate, while some endpoints carry a different cost that developers can check through Kalshi's endpoint-costs route.
The documented Basic tier receives 200 Read tokens and 100 Write tokens per second. Advanced receives 300 for each bucket. Higher tiers rise with trading volume or assignment by Kalshi. A rate-limited request returns HTTP 429, and Kalshi directs clients to use exponential backoff.
Batch calls do not reduce token cost. Kalshi charges each item in a batch, and the whole batch must fit inside the available bucket. Check current limits from the API before sizing request traffic. Developers need to design around the limits before launch.
Should you build on the Kalshi API or use a trading terminal?
Build on the Kalshi API when proprietary code creates the trading advantage. A custom model, automated quoting logic, or a private data pipeline can justify owning authentication, deployment, monitoring, and order-state recovery. The API gives the software direct access to one venue.
Use a trading terminal when the advantage comes from seeing and executing the trade. Kairos puts Kalshi, Polymarket, and Predict.fun in one book with sub-second data, aggregation, advanced order types, and low-latency execution. The trader gets professional infrastructure without building the plumbing first.
The split is clean. Developers who need custom automation should use the API. Active traders who need cross-venue prices and execution should use Kairos. Event contracts carry real market risk in either workflow. Traders still own every decision that reaches the order book.
Sources
Kalshi API documentation confirms REST, WebSocket, and FIX support for real-time market data and trade execution. Kalshi's market data quick start documents public endpoints that work without authentication.
Kalshi's API key guide documents key creation, RSA request signing, and the required authentication headers. Kalshi's environment guide lists the production and demo hosts. Kalshi's rate-limit guide documents token costs, tier budgets, batch behavior, and HTTP 429 responses.
Kairos product details come from the live Kairos offer. See you in the order books.
Where a Kalshi bot fits
A Kalshi bot turns the API into an automated trading loop. It reads market data, applies a predefined rule set, and sends orders without manual input. Traders still need deployment, monitoring, risk limits, and clean order-state recovery.