The Kalshi API is a REST and WebSocket interface that lets you read live market data and place orders on Kalshi programmatically, without going through the web UI. It's how every Kalshi trading bot, market-making script, and cross-platform arbitrage agent actually talks to the exchange.
If you're a developer evaluating whether to build on it, the short version is: it's a real, CFTC-regulated exchange API with proper order books and authenticated trading — not a scraped or unofficial wrapper — but it comes with signing requirements, rate limits, and a WebSocket feed that behaves differently from a typical crypto exchange feed. Here's what actually matters before you start building.
What the Kalshi API actually gives you
Two surfaces: a REST API for account actions (placing orders, checking positions, fetching historical data, listing markets) and a WebSocket API for real-time updates (order book changes, fills, ticker updates). Almost every serious bot uses both — REST for one-off account and market-lookup calls, WebSocket for anything that needs to react to price movement without polling.
Authentication: RSA-signed requests, not just an API key
Kalshi doesn't use a simple bearer token. Every private request is signed with an RSA private key you generate and register with your account — the request timestamp and method get signed, and Kalshi verifies the signature server-side. This is stricter than most retail trading APIs, and it's a common place for a first integration to go wrong: a clock skew of a few seconds, or signing the wrong string, produces an authentication failure that looks identical to a bad key.
Key endpoints you'll actually use
- Markets: list and filter markets by series, event, or status — this is how a bot discovers what's tradeable and when it closes
- Orderbook: current bids and asks for a market, in cents — the foundation for any spread or arbitrage calculation
- Orders: place, cancel, and query order status — market and limit orders, with time-in-force options
- Positions and fills: what you currently hold and your execution history, needed for P&L tracking and reconciliation
- Portfolio balance: available buying power, which any position-sizing logic needs to check before firing an order
Rate limits
Kalshi enforces rate limits on both REST calls and WebSocket subscriptions, and they scale with account tier. In practice this means a bot polling REST endpoints aggressively for near-real-time data hits limits well before a bot that subscribes to the WebSocket feed for the same information — REST is fine for account actions and periodic market discovery, but it's the wrong tool for watching order books tick by tick.
The WebSocket feed, and why it's not "set and forget"
The WebSocket connection needs its own application-level keepalive — relying on the underlying protocol ping alone isn't sufficient in practice — and subscriptions need to be re-established after any reconnect. A feed that silently drops and never reconnects looks, from the outside, exactly like a market that stopped moving. Any bot trading off this feed needs a health check that's independent of "are messages still arriving," because a stalled subscription and a quiet market produce the same silence.
Building a bot vs using a hosted agent
Building directly on the Kalshi API gets you full control, but the actual work isn't the API calls — it's everything around them: reconnect logic, signature generation, rate-limit backoff, position reconciliation, and (if you're trading cross-platform) matching Kalshi's markets against equivalent events on another venue like Polymarket, which almost never share identical titles or resolution wording. That matching problem is usually harder than the API integration itself. A hosted platform like Arbitrage Agent handles the Kalshi and Polymarket connections, AI matching with every pair validated, and net-edge calculation after fees, so you're evaluating opportunities instead of debugging a signed request.
Common pitfalls when building on the Kalshi API
- Treating cents as dollars (or vice versa): Kalshi prices and P&L are denominated in cents in several endpoints and CSV exports — a missed conversion silently inflates or deflates every number by 100x. We cover the same trap on the reporting side in our guide to tracking Kalshi P&L for taxes.
- Assuming the WebSocket never drops: it does, and a bot that doesn't detect and recover from a stale connection will trade on data that stopped updating minutes ago.
- Polling REST for data the WebSocket already pushes: this burns your rate limit for no benefit and adds latency versus just subscribing.
- Skipping signature edge cases: clock drift and encoding mismatches are the most common source of "my key doesn't work" reports that are actually signing bugs.
Should you build on the API directly?
If you're building a single-platform strategy specific to Kalshi and you're comfortable owning the operational plumbing — reconnects, signing, rate limits — the API is solid and well-documented enough to build on directly. If your goal is cross-platform arbitrage against Polymarket, the API integration is the easy part; matching, spread calculation, and execution timing across two exchanges is the hard part, and that's what a purpose-built agent already solves. Arbitrage Agent's Starter plan ($29/month) runs in dry-run mode so you can see real detected spreads before committing capital, or join the waitlist for early access.