Kalshi Trading Bot: How API and Market-Making Bots Work
A Kalshi trading bot is a program that talks to Kalshi's own API instead of a human clicking buttons — same order book, same fees, same settlement rules, just automated. Kalshi runs a public REST and WebSocket API at api.elections.kalshi.com/trade-api/v2, and it's used by everyone from a retail trader running a single-strategy script to firms quoting dozens of markets at once. This piece covers what a bot actually does on Kalshi, the difference between a taker bot and a market-making bot, where bots go wrong, and the safety rails that keep an automated strategy from doing real damage.
What a Kalshi trading bot actually does
At the base level, a bot is a loop: read market data, decide, send an order, repeat. On Kalshi that means polling or subscribing to the order book endpoint (/markets/{ticker}/orderbook) or the WebSocket feed, running that data through a strategy function, and calling the order-entry endpoints to place, amend, or cancel. Kalshi's book returns bids only — a YES bid at $0.62 is the same thing as a NO ask at $0.38 — so a bot has to translate that into whichever side it wants to trade before submitting.
Three broad categories of bots run on Kalshi:
- Signal/taker bots — cross the spread when a model disagrees with the current price, betting the edge is bigger than the taker fee.
- Market-making bots — post resting limit orders on both sides, earning the spread and paying the lower maker fee, without a directional view.
- Arbitrage bots — watch a related market (another Kalshi strike, Polymarket, or an external price feed) and trade the mispricing between them.
API bots vs. market-making bots: what actually changes
The mechanical difference is order type and intent, but it changes the economics. Kalshi's taker fee is round_up(0.07 × contracts × price × (1−price)), peaking at $1.75 per 100 contracts at a 50-cent price. Maker fee is 25% of that — about $0.44 per 100 contracts at the same price. A bot that only takes has to clear that full fee on every round trip; a bot that makes markets by resting orders pays a quarter of it, which is why most serious automated Kalshi strategies lean market-making rather than pure signal-taking. The tradeoff is that a resting order can sit unfilled, or get filled by someone with better information right before the market moves against you — the classic adverse-selection problem for any market maker.
| Bot type | Fee exposure | Main risk |
|---|---|---|
| Taker/signal | Full taker fee, up to $1.75/100 | Model edge doesn't beat fees + slippage |
| Market-making | Maker fee, ~25% of taker | Adverse selection, inventory risk |
| Arbitrage | Depends on venues traded | Execution lag between legs |
Where bots actually go wrong
Almost every bad bot story is the same shape: a strategy that worked fine in normal conditions kept running into conditions it wasn't built for. A feed disconnect that leaves stale quotes resting in a fast-moving book. A retry loop that keeps re-sending an order after a rejection instead of stopping. A model that doesn't know a scheduled data release (CPI, FOMC, a game going final) just happened and keeps quoting the pre-release price. None of these require a coding error — they're all "the bot did exactly what it was told, and what it was told turned out to be wrong at 2am when nobody was watching."
Unattended automation compounds mistakes at machine speed. A human trader who fat-fingers a size typically catches it on the next order; a bot with no limit checks will happily repeat the mistake fifty times in the time it takes to notice.
Safety rails: what a bot needs before you leave it unattended
- Kill switch. A single control — manual or triggered — that cancels all resting orders and halts new order submission immediately.
- Dead-man switch. If the bot's connection to Kalshi drops or the process stops heartbeating, all working orders get pulled automatically rather than sitting live with no one watching them.
- Drawdown auto-disarm. A hard loss threshold — daily or per-session — that disables new trading the moment it's crossed, instead of relying on a human to notice the account is bleeding.
- Position and size limits. Hard caps per market and in aggregate so one bad signal can't stack unlimited size.
These aren't optional extras for a "serious" bot — they're the difference between an automated strategy and an unsupervised script with your bankroll attached to it.
Run bots with the rails already built in
PolyMarketMaker's automated quoter ships with a kill switch, a dead-man switch, and automatic drawdown disarm on every strategy, so a dropped connection or a bad print doesn't turn into an unattended loss. PolyMarketMaker runs market-making and quoting logic across Kalshi and Polymarket from one desktop terminal. Simulation $149/mo, Live Trading $299/mo.
Latency, infrastructure, and realistic expectations
A retail bot running on a home connection or a cheap cloud instance is not competing on raw speed with a firm colocated near an exchange's matching engine — and on Kalshi, it mostly doesn't need to. Most retail-viable edges come from patience and structure, not microsecond reaction time: quoting a strike nobody's watching closely, sizing correctly around a scheduled release, or catching a mispricing that persists for minutes rather than milliseconds. Chasing pure speed against better-resourced competitors on a crowded strike is usually a losing game; a bot that's disciplined about where it competes tends to outlast one that's just fast.
That said, uptime still matters more than most builders expect going in. A bot that's down for an hour during a CPI release didn't just miss an opportunity — if it had resting orders live going into the release and lost its connection, those orders can still get filled at stale prices with nobody watching. This is exactly what a dead-man switch is for: no heartbeat, no live orders, full stop.
Building vs. buying a Kalshi bot
Building your own means wiring up the API directly — authentication, the orderbook endpoint, order management, and reconnection logic — which is a real project even before you write a strategy. It also means you own every safety rail yourself; nothing stops a bot from running unattended except code you wrote. Third-party and off-the-shelf tools handle the plumbing and often the safety rails too, at the cost of less control over exact execution logic. Either path, test in a paper or simulation environment before risking live capital — a strategy that looks profitable on a backtest can still break the first time it meets a live, thin order book. See Kalshi API trading for the authentication and endpoint details, and backtesting prediction markets before going live.
FAQ
What is a Kalshi trading bot?
A program that connects to Kalshi's REST or WebSocket API to place, cancel, or adjust orders automatically based on rules you define, rather than clicking buttons in the web app.
Is running a bot on Kalshi allowed?
Yes — Kalshi publishes a public API for programmatic trading at api.elections.kalshi.com/trade-api/v2, used by retail and professional traders alike.
Do market-making bots pay lower fees than taker bots?
Generally yes. Maker fee is 25% of the taker fee on the same trade, so posting resting orders instead of crossing the spread cuts per-contract cost significantly.
What's the biggest risk of running a Kalshi bot unattended?
A bot that keeps quoting or re-entering after a bad fill, feed outage, or runaway loop can compound losses at machine speed with no kill switch or drawdown limit in place.
What safety rails should a Kalshi bot have?
A manual kill switch, a dead-man switch that pulls orders on disconnect, and an automatic drawdown disarm that halts trading past a preset loss threshold.
For the full API setup walkthrough see Kalshi API trading, and for the broader strategy picture start with the Kalshi trading guide or Kalshi trading strategies.
This article is for educational purposes only and is not financial advice. Trading involves risk of loss.