Prediction Market API Trading: Automating Event Contract Strategies on Kalshi

Overview #

Most prediction market trading is manual. You open Kalshi, check a market, place an order, and check back hours later. That works fine if you're trading one or two events you follow closely. It stops working when you want systematic exposure across dozens of markets, consistent position sizing, automated monitoring, or any strategy that depends on reacting to information faster than a human refresh cycle can manage.

The Kalshi REST API makes automated trading possible for any programmer. It's not complex — the endpoint set is smaller than most broker APIs — but the behavioral patterns for event contract automation differ meaningfully from traditional futures bots. Event contracts have binary outcomes, fixed expirations, no margin mechanics, and a daily request budget that requires deliberate conservation. Building for these constraints from the start is the difference between a bot that survives real trading and one that burns through its daily API budget in four hours or double-places orders after a crash restart.

This guide covers the full stack: API authentication and token management, market data retrieval with pagination, idempotent order placement with retry logic, rate limit management, strategy backtesting with historical data, risk controls, and production deployment practices. The code examples are Python, but the patterns apply to any language.

One context note before the technical content: as of mid-2026, Kalshi has established regulatory footing as a CFTC-designated contract market, which gives it legal standing that earlier prediction market platforms lacked. Political event contracts are live alongside economic, sports, weather, and financial events. The market is more liquid than it was two years ago, which matters for automated strategies that depend on order book depth. Polymarket, operating in parallel as a decentralized alternative, has a different API structure and different regulatory constraints — the patterns here are specific to Kalshi's REST API.

If you're already comfortable with the Kalshi web interface and want to understand how to systematically approach dozens of markets at once, this is the starting point.

API Architecture: How Automated Systems Connect #

Kalshi's REST API lives at api.kalshi.com/trade-api/v2/ and requires TLS 1.2 or higher. All requests and responses use JSON. Authentication uses Bearer tokens obtained via a login endpoint — you send your email and password, receive a JWT token with a 24-hour lifetime, and include it as a header on all subsequent requests. The token needs to be refreshed before expiry, which is trivial to implement but easy to forget until you get a string of 401 errors at 3 AM.

The endpoint surface breaks into four functional categories. Markets endpoints give you listings, order books, and price history. Order endpoints handle placement, cancellation, and status checking. Portfolio endpoints track positions, cash balance, fills, and settled contracts. Market data endpoints provide candlestick history and exchange health status. That's the entire API. If you've built bots for futures brokers, you'll find this smaller and simpler — the complexity in prediction market automation comes from the operational patterns, not the API surface.

The daily request limit is 10,000 requests per account, resetting at midnight UTC. This sounds generous until you do the arithmetic: 10,000 requests over 24 hours is 416 per hour, or roughly 7 per minute sustained. A naive bot that polls 200 open markets every 5 minutes sends 2,400 requests per hour — it exhausts the daily budget in four hours and stops working for the rest of the day. Every architectural decision in Kalshi automation needs to account for this constraint explicitly, not as an afterthought.

All list responses use cursor-based pagination. The API returns up to 100 records per call plus a cursor token for the next page. If you don't implement cursor handling, you'll silently miss markets when the total count exceeds 100 — and Kalshi has many more than 100 active markets. This is the most common source of silent data gaps in beginner implementations.

Authentication Pattern: Token Management That Won't Break at 3 AM #

The auth flow is: POST to /login with your credentials, get back a Bearer token, include that token in the Authorization header on every subsequent request. The token expires after roughly 24 hours. The practical implementation wraps this in a client class that tracks the expiry time and refreshes automatically before any request that would fail with a stale token.

Never hardcode credentials in your source code. Use environment variables: KALSHI_EMAIL and KALSHI_PASSWORD loaded at startup. If you're storing them in a configuration file, make sure that file is excluded from version control via .gitignore. A leaked API credential in a public repository means someone else can trade on your account. This has happened to enough people in automated trading generally that it deserves explicit mention.

The token expiry tracking pattern is straightforward: store the epoch time when the token was obtained, subtract a safety margin (say, 3600 seconds), and check before every API call whether the current time exceeds that threshold. If it does, call login again before proceeding. This eliminates the 401 error cascade that happens when a token expires mid-operation.

Market Data: Getting Order Books and Price History #

The starting point for any automated strategy is GET /markets with a status filter for open markets. This returns paginated market objects that include the ticker, event title, resolution criteria, close time, and current YES/NO prices. Your bot needs to iterate through all pages using the cursor field to get a complete market picture.

Each market has a unique ticker — something like FED-25DEC-T4.75 for a Fed funds rate decision contract, or ECON-25JAN-CPI-T+0.2 for a CPI event. These tickers are what you use to reference markets in order placement. The naming follows a pattern, but don't try to construct tickers programmatically — always look them up via the API to get the exact string.

Order book depth comes from GET /markets/{ticker}/orderbook. The response gives you arrays of [price, quantity] pairs for the YES bid and ask sides. Prices are in cents (1-99). A YES bid of [72, 150] means someone is willing to buy 150 YES contracts at 72 cents each. The spread — best ask minus best bid — tells you the cost of immediate execution. In liquid markets like major Fed meetings, this is typically 1-2 cents. In less-followed markets, it can be 5-10 cents or wider, which materially affects strategy viability.

Price history comes from GET /markets/{ticker}/history, which returns a time series of market prices. This is useful for short-term pattern analysis but has limited lookback depth. For backtesting purposes, you'll want to supplement Kalshi's own history with external data sources — the FRED database for economic outcomes, CME FedWatch for implied probabilities, and Polymarket's GraphQL API for cross-platform comparison where both cover the same event.

Bobwest on the NexusFi forums noted an important structural point when CME first launched event contracts: "Without having looked at it too closely, this seems to me to be similar, if not the same, as binary options: you're buying a binary payoff." (Thread: Event Contracts - New Way to trade CME Futures). That framing captures the essential mechanics — the automated trading implications follow from that binary structure directly.

Order Placement: Idempotent, Retryable, Deduplication-Safe #

The order placement endpoint is POST /portfolio/orders. The required fields are ticker, side (yes or no), type (limit or market), count (number of contracts), and yes_price for limit orders. The yes_price field is in cents, 1-99, representing the price per YES contract. A yes_price of 72 means you're bidding 72 cents for each YES contract. Since NO contracts are the complement, a YES price of 72 implies a NO price of 28 (the market clears at $1.00 total).

The most important optional field is client_order_id — your own reference string for the order. This enables idempotent order placement. If your POST request times out and you don't know whether the order was placed, you can retry with the same client_order_id. Kalshi will accept the retry and return the existing order rather than creating a duplicate. Without this, a network timeout during order placement creates uncertainty: did the order land or not? You either risk placing a duplicate (buying twice what you intended) or missing the trade entirely. The client_order_id eliminates this uncertainty at zero cost.

Implement a retry loop with exponential backoff for order placement: try three times with 1-second, 2-second, and 4-second delays between attempts. On each attempt, use the same client_order_id. If you receive a 409 Conflict response, the order already exists — return the existing order ID and continue. If you receive a 201 Created, return the new order. If you exhaust retries, log the failure and alert — don't silently drop the order.

Market orders fill at whatever the current best price is when the order hits the book. For strategies that need to get a position quickly (reacting to a news break), this is appropriate. For strategies that are building a position in a stable market, limit orders are almost always better — you avoid crossing the spread and paying both sides. The spread on a major market might be 2 cents: 74 bid, 76 ask. Placing a market order to buy YES means you pay 76 rather than 74. That 2-cent disadvantage on 100 contracts is $2.00 — not enormous, but it compounds across many trades.

Building a Strategy: The Fed Decision Arbitrage Example #

One of the simplest systematic approaches to Kalshi is comparing Kalshi event contract prices to external probability estimates for the same event. The Fed rate decision is the cleanest example because the CME Group publishes the 30-Day Fed Funds futures-implied probability of rate decisions through their FedWatch tool, and Kalshi runs active markets on those same decisions.

The hypothesis: when Kalshi's YES price for a specific Fed outcome diverges from CME's implied probability by more than some threshold, one of the two markets is mispriced, and the correct trade is to fade the divergence. If CME implies 85% probability of a hold and Kalshi has YES contracts for hold at 74 cents (74% implied probability), there's an 11-point gap. Either CME is too high or Kalshi is too low. The bet is that they converge before resolution.

Implementation steps: (1) Fetch CME FedWatch data for the next FOMC meeting from their public API or CSV export. (2) Get the current Kalshi YES price for the equivalent contract. (3) Calculate the divergence: CME probability minus Kalshi price in cents. (4) If divergence exceeds your threshold (say, 8 points) and the market has sufficient volume, submit a limit order. (5) Set an exit target at convergence (the divergence closes to 2 points or less) and a stop at maximum adverse divergence.

(Thread: NFA Raises Concerns About Direct Clearing for Retail Derivatives Traders). That structural difference matters for sizing models — max loss per trade is always exactly the premium paid.

What the historical backtest of this strategy shows is sobering: high win rates don't guarantee positive expectancy when the losses are structurally larger than the wins. In the Fed decision context, when you buy YES at 74 because CME implies 85%, and then the Fed actually cuts, your YES contracts go to zero — a loss of $0.74 per contract. When you win, you collect from 74 cents to $1.00 — a gain of $0.26 per contract. You need to win more than 74% of the time to break even on this specific entry. Market efficiency in Kalshi Fed markets has improved much since 2023, and genuine pricing gaps are rarer and smaller than they used to be. Backtesting rigorously before live trading reveals whether any edge remains in your specific variant of the strategy.

The framework generalizes beyond Fed decisions: CPI prints, NFP reports, earnings event contracts on Robinhood and Kalshi, weather contracts. Each event category has its own external reference market or estimate you can use as a signal anchor. The discipline is the same: gather external probability estimate, compare to Kalshi price, define a threshold for action, size the trade using Kelly or fixed fractional, and backtest before live deployment.

Rate Limit Management: The Architectural Problem You Solve First #

The 10,000-request daily limit requires treating API calls as a finite budget, not an unlimited resource. A naive implementation polls every market on every schedule regardless of whether anything changed. A smart implementation uses tiered polling frequencies, local state caching, and budget monitoring to stay well under the limit while maintaining adequate market awareness.

Tiered polling based on time-to-resolution is the most impactful optimization. Markets resolving within 48 hours need frequent monitoring — prices move quickly near resolution as new information arrives and traders react. Markets resolving in 7+ days change slowly and can be polled hourly. A practical breakdown: hot markets (less than 48 hours) poll every 2 minutes for 720 requests per market per day; warm markets (2-7 days) poll every 15 minutes for 96 requests per day; cold markets (more than 7 days) poll hourly for 24 requests per day. If you're tracking 150 markets split across these tiers, total scan requests run around 2,200 per day — well within budget.

Delta polling reduces order book fetches further. Instead of fetching the full order book every scan cycle, store the last YES price for each market. Only fetch the order book if the price has moved by more than 1 cent since the last fetch. In stable markets between significant events, prices change infrequently — a market that's been sitting at 84 cents for 6 hours doesn't need 72 order book fetches over that period. Delta-gated fetching cuts order book requests by 70-80% in practice.

Build a request counter into your bot from the first day. Log every API request, track the daily total, and implement rate responses: at 7,000 requests, switch to minimum-frequency polling; at 9,500, disable all scanning and only process order confirmations; at 9,800, halt completely and alert. An alert at 9,800 requests means you're dangerously close to the limit but still have 200 requests for emergency operations. Hitting 10,000 without a graceful degradation path means your bot goes silent in the middle of active trading.

Position Management and P&L Tracking #

Once orders start filling, you need to track what you own, what it cost, and what it's currently worth. The Kalshi portfolio endpoints provide this: GET /portfolio/positions returns open positions, GET /portfolio/fills returns execution history, and GET /portfolio/balance returns your cash balance. For an automated strategy, you should maintain this state locally and reconcile against the API periodically rather than relying on real-time API queries for every decision.

Local state structure for each position: market ticker, side (yes/no), quantity, average fill price, unrealized P&L at current market price, and the order IDs associated with this position. Update this state after every fill confirmation. Every 15 minutes, reconcile your local state against the portfolio API to catch any discrepancies — orders that filled while your bot was processing something else, settlements that arrived, or fills from manual orders placed through the web interface.

P&L calculation for binary event contracts is straightforward: unrealized P&L equals (current_market_price - avg_fill_price) x contracts for long positions, and the reverse for shorts. Realized P&L at settlement is (settlement_value - avg_fill_price) x contracts, where settlement_value is $1.00 for the winning side and $0.00 for the losing side. Track both separately — unrealized P&L gives you a sense of how positions are performing before resolution, realized P&L tracks actual outcomes.

Prediction market P&L has a different risk profile from futures P&L. In futures, an adverse 1% move in the underlying causes a leveraged loss that can exceed your position value if you're trading on margin. In event contracts, your maximum loss is always the amount you paid. A YES position bought at 72 cents can lose at most 72 cents per contract regardless of what happens. This makes max loss calculation trivial and eliminates margin call risk entirely — but it also means gains are capped at (100 - entry_price) cents per contract.

Correlation Risk: Why Your "Diversified" Book Might Not Be #

Automated prediction market books often look diversified on the surface — different event types, different resolution dates, different sectors. The correlation structure beneath tells a different story. Fed rate decision markets, Treasury yield event contracts, and CPI outcome contracts correlate at 0.6-0.8. Holding positions in all three simultaneously doesn't triple your edge exposure — it multiplies your tail risk when any single macro factor (unexpected Fed pivot, inflation surprise) moves against all three at once.

The practical risk control: limit any single directional macro factor to 40% of total book exposure. If you have positions net-long "rates stay high" (Fed holds + 10Y stays elevated + CPI stays elevated), cap that correlation bucket before adding the next trade. The mechanical enforcement requires categorizing each market by its primary driving factor and tracking bucket concentrations in your position management code, not just in your head.

Inverse positions can genuinely reduce correlation risk when they're economically opposite: YES on "Fed holds" and YES on "Fed cuts" is a hedge that locks in a small loss (you lose the spread on whichever side loses). But be careful about pseudo-hedges: YES on "Fed holds December" and YES on "Fed holds January" look like they're on opposite sides of the calendar but are actually highly correlated — the same policy trajectory drives both outcomes. Correlation risk analysis needs to look at the underlying economic driver, not just the contract labels.

Backtesting: How to Test Before Going Live #

Backtesting event contract strategies requires historical market data that Kalshi provides for closed markets through the history endpoint. The quality and depth of this history has improved as the platform has matured — markets from 2022-2023 may have limited resolution, while 2024+ markets generally have more complete price series. For economic event strategies, supplement Kalshi data with FRED for actual outcomes, CME for futures-implied probabilities, and news data for timing information.

The backtesting framework for a signal-driven strategy has four components: a data collector that assembles historical Kalshi prices plus external signals, a signal generator that applies your rules to historical data to produce hypothetical trades, an execution simulator that applies realistic slippage (assume you pay the ask when buying, receive the bid when selling), and a performance analyzer that calculates P&L, win rate, Sharpe ratio, and maximum drawdown.

Be rigorous about look-ahead bias. If your strategy uses CME FedWatch probabilities as a signal, make sure you're using the probability as it stood at the time of the hypothetical trade entry, not the final pre-meeting probability. CME FedWatch probabilities drift much in the weeks before a meeting as new data arrives. Using the final day's probability to signal a trade that would have been placed two weeks earlier inflates historical performance in ways that never translate to live trading.

Advanced Patterns: Monitoring Multiple Events #

A bot monitoring multiple concurrent events needs to prioritize which markets deserve attention at any given time. The relevance hierarchy for event contract automation: markets resolving within 24 hours get highest priority, active price movement (recent trades in the history) signals potential opportunity, and markets near 50 cents on either side have more trading activity than markets at 90+ cents (near-certain outcomes).

Event scheduling is a useful automation primitive. Most economic events have fixed announcement times: FOMC announcements at 2 PM ET, CPI at 8:30 AM ET, NFP at 8:30 AM ET. Build a schedule into your bot that increases polling frequency in the 30 minutes before these announcements and immediately after. The 10 minutes following a scheduled announcement is when prices move fastest and where execution timing matters most — if you're going to take a position based on the announcement, having the order in before the announcement is almost always better than reacting to it.

The correlation structure across concurrent events matters for portfolio-level risk. As detailed in the correlation section above, Fed, CPI, and Treasury markets correlate at 0.6-0.8. A bot that monitors all three and applies the same signal framework to each will build a highly correlated book without explicit position limits by correlation factor. Implement the bucket limits in code, not as a mental note to check periodically.

Watchlist management keeps the bot focused on markets that actually match your strategy. Maintain a filtered list of markets that meet your criteria — minimum volume, specific event categories, resolution within a target time window — and only run the analysis loop on watchlist markets. Update the watchlist at the start of each day and when new relevant markets open. This combines with tiered polling to keep request volume manageable while ensuring coverage of the markets that matter.

Risk Controls: What Keeps the Bot From Destroying Your Account #

Automated trading without explicit risk controls has a failure mode that manual trading usually avoids: the bot can execute dozens of trades in the time it would take you to realize something is wrong. A signal bug that causes the bot to buy YES contracts on markets where it should be neutral can create a large concentrated position before any human notices. Risk controls are the circuit breakers that limit damage when bugs, data errors, or unexpected market conditions cause the bot to behave incorrectly.

Position limits set the maximum exposure per market and per account. A reasonable starting framework: no more than $500 notional in any single event market, no more than 10 concurrent open positions, and no more than 3% of total account balance in any single event category. These aren't derived from theory — they're conservative starting points that prevent a single wrong trade from being catastrophic while you develop confidence in the strategy. Adjust based on your backtested Sharpe ratio and actual realized volatility.

Daily loss limits act as a circuit breaker for the session. If the account drops 2% from its starting balance in a day, halt all new orders and alert. If it drops 1% within any 4-hour window, pause and reassess. Three consecutive losing trades trigger a review before the next trade. Implement these as hard checks that run before every order placement — not as soft warnings that can be bypassed.

The emergency stop is a distinct function: cancel all open orders and halt all new order placement. On Kalshi, DELETE /portfolio/orders cancels all open orders in a single call. This is the function you call when the monitoring system detects anomalies — unusual P&L swings, unexpected order patterns, rate limit exhaustion, or loss of connectivity to external data sources that your signal depends on. Build the emergency stop first. Test it before you place your first live order.

Production Deployment: From Working Bot to Safe Bot #

There are eight steps between a bot that works in testing and a bot that's safe in production. Skip any of them and you're relying on luck.

State persistence means storing all order and position information in a local database, not just in memory. When your bot restarts — and it will restart, whether from a crash or a routine restart — it needs to query GET /portfolio/orders and GET /portfolio/positions to reconcile its local state against what actually exists at Kalshi. A bot that doesn't do this will attempt to place orders that already exist, creating duplicates that accidentally double your position.

Credential security means API keys live in environment variables, not in source code or configuration files committed to version control. Use a separate read-only API key for your monitoring dashboard and a read-write key for the trading bot itself. If the monitoring key is compromised, nothing trades. Rotate credentials after any security event.

Paper trading is running your full strategy stack with real market data but without submitting actual orders. Implement a --dry-run flag that skips the POST to the order endpoint and logs the hypothetical order instead. Run this mode for two weeks minimum before live trading. Compare your paper trade outcomes to what the market did — if the paper strategy is systematically profitable in ways that aren't reflected in backtests, either you've found a genuine edge or you have a look-ahead bias in your paper implementation.

Error taxonomy means your code handles each HTTP error code specifically, not generically. HTTP 400 means a bad request — log the full payload and fix the bug. HTTP 401 means authentication failure — refresh the token immediately. HTTP 429 means you've hit the rate limit — implement exponential backoff and don't retry aggressively or you'll make the problem worse. HTTP 503 means the API is temporarily unavailable — wait and retry with backoff. Each error has a different correct response; treating them all as "try again" creates bots that exacerbate problems.

Reconciliation runs on a schedule: every 15 minutes, compare your local view of positions and balance against the API. Alert on any discrepancy above a small threshold. Reconciliation catches fills that arrived while your bot was processing something else, settlements that reduced your balance, and manual trades placed through the web interface that your bot doesn't know about.

Graceful shutdown handles SIGTERM properly: cancel all open orders, wait for cancellation confirmation, flush all state to the database, then exit. A bot killed with SIGKILL leaves open limit orders that might fill at unexpected times. On a volatile day, a limit order placed hours ago at a price that seemed reasonable might fill during a gap that moves the market past your price — and there's no position management logic running to handle it because the bot is dead.

Monitoring surfaces the information that matters: real-time P&L, API request count and error rate, current open positions, and alerts for any condition that requires human attention. You don't need a complex dashboard — a simple status page that shows these four things is sufficient for initial deployment. Add sophistication as you understand which metrics actually help you catch problems faster.

The incident runbook is documentation for the scenarios you hope don't happen. Write down, before they occur: how to manually cancel all open orders via the Kalshi web interface, how to revoke and regenerate your API key, the sequence for a clean restart after a crash, and who to contact (yourself, at minimum) when an alert fires. Panic decisions during a live incident are how recoverable problems become unrecoverable ones. The runbook means you're executing a plan rather than improvising.

What Automated Prediction Market Trading Is Good At -- and What It Isn't #

Automated Kalshi trading has genuine advantages over discretionary trading in this space: consistent position sizing that doesn't vary based on mood, coverage of more markets than any human can manually follow, precise execution timing around scheduled events, and the ability to run backtests on your strategy before risking capital. For traders who have a well-defined systematic thesis about event contract pricing — a belief about when markets misprice Fed decisions, economic outcomes, or geopolitical events — automation lets you express that thesis consistently across many opportunities.

The limitations are also real. The API request budget is a hard constraint that limits how many markets you can monitor continuously. Kalshi's order book depth in less popular markets is thin enough that automated strategies can move prices against themselves if position sizes are large relative to available liquidity. Binary outcomes create loss distributions that differ from futures: individual trades can lose their entire cost, which demands tight position limits and portfolio-level risk management that some traditional trading systems aren't designed for.

The strategies that translate well to automation on Kalshi are the ones that don't require sub-second execution (the API latency and request budget don't support that), work across many markets rather than requiring deep specialization in one, have a systematic signal that can be expressed in code, and have edge that survives realistic transaction costs including the bid-ask spread. Fade-the-divergence strategies like the Fed arb example, systematic coverage of economic data releases, and hedging event risk on existing futures positions are all candidates. High-frequency market making on Kalshi is probably not viable for retail-scale automation given the API structure and competition from professional market makers.

The field is still early enough that systematic approaches have more room to find edge than comparable approaches in mature futures markets. Kalshi's liquidity and pricing efficiency have improved much since launch, but event contract markets are not yet as efficiently priced as CME futures across all event categories. The trader who builds solid infrastructure, tests systematically, and runs tight risk controls has a real opportunity to find and exploit these inefficiencies before the market closes them. The technical foundation in this guide is the starting point for that work.