Kalshi API Rate Limits for Automated Trading Bots

An automated trading bot must operate within Kalshi API rate limits to execute, recover, and protect its account under load. Its token-bucket architecture makes those constraints predictable, but only if the bot accounts for shared capacity, changing endpoint costs, and recovery without a Retry-After header. That work belongs before trading logic.

Why Kalshi's rate limit architecture is the first engineering problem to solve, not the last

An automated trading bot needs capacity both to manage existing exposure and to place its next order. A system that spends its budget without preserving that capacity can lose the ability to respond when it matters. Kalshi’s combination of independent buckets, tiered refill rates, and account-wide limits therefore sets an engineering boundary. A strategy is not operationally complete until its traffic fits within that boundary.

The Developer Agreement §3 limits API use to facilitating a member’s own trading on the exchange. The bot trades the account holder’s capital, and its recovery behavior must respect that account’s shared resources. Because a rate-limit response supplies no Retry-After header, recovery cannot depend on the exchange prescribing a wait. Backoff and state correctness must be designed before the trading logic depends on them. Those designs must also accommodate API changes, since an endpoint’s cost or response shape can invalidate assumptions that once held.

How the two-bucket token system works and what each bucket covers

The core model has separate read capacity and write capacity. A request draws tokens from the bucket assigned to its operation, while each bucket replenishes at its own rate. This separation matters because spare capacity in one bucket does not establish capacity in the other. A bot must account for the operation it wants to perform rather than treat all available tokens as interchangeable.

REST and FIX requests drain the same buckets, so using both connection methods does not give the account more tokens. A scheduler that tracks those methods separately without accounting for their shared consumption would misstate the available budget.

The October 2026 balance-bucket split also means that which bucket an endpoint uses matters at deployment. A bot that polls balance often cannot safely assume it still uses the same bucket. The core read/write model explains the constraint, but the current endpoint assignment determines where a particular call draws capacity. Balance polling needs that explicit check before its cost is folded into the traffic plan.

What each tier actually grants and how tiers are earned

Tier allowances describe account-wide refill rates shared by workers. Basic gives the account 200 read tokens per second and 100 write tokens per second. Advanced permanently doubles the Basic write budget through a free self-serve call and unlocks production batch endpoints. These grants change how much traffic the account can sustain, but they do not remove the need to account for individual operation costs.

Higher tiers scale those refill allowances, with access tied to volume-share thresholds. The distinction between earning a tier and consuming its budget is important. Volume share sets which tier an account can use, while bucket refill sets how much traffic it can handle. Neither a tier name nor access to batching establishes how many orders a bot can send without knowing the relevant token cost.

The June 2026 automation of tier upgrades is a recent operational change. How tiers are handled should therefore be checked when the bot’s capacity plan changes. An upgrade increases available throughput, but it does not change the underlying need to schedule against separate buckets. The effect of volume-share thresholds on new builders is a separate design problem, addressed after the mechanics.

Burst capacity and what happens when a bucket empties and refills

A bucket accumulates tokens up to a cap. That cap sets the largest burst it can absorb, while the refill rate sets sustainable throughput. These are different limits, and a bot can stay within one while exceeding the other. Traffic that appears acceptable when averaged over time can still empty a bucket if it arrives together.

At Premier tier, each order costs ten tokens. Sustainable order throughput therefore follows from the write refill rate divided by that cost. Burst capacity follows from the tokens currently available, subject to the bucket’s cap. A full bucket can accept a burst that an almost-empty bucket cannot, even though the account’s tier is unchanged.

Once the bucket empties, refill begins restoring the capacity needed for another operation. A 429 does not impose an additional penalty on that process. At Premier, recovery for a single order is a brief pause governed by the refill rate and the ten-token requirement. The retry policy should allow for that recovery and wait until enough capacity is available before trying again.

Why the budget is account-wide and how that shapes bot architecture

Every worker, thread, and connection on an account shares its token budget. Three parallel workers at Basic have 200 read and 100 write tokens per second in total. A local view of consumption cannot establish what the account has left.

The architectural response is a priority queue that lets protective traffic pre-empt market polling when capacity is tight. Cancellations and position reconciliation must go ahead of discretionary traffic even when that traffic arrived first. Their needs still have to be accounted for in the relevant buckets. A read spike competes for read capacity, while order placement requires write capacity, so account-wide accounting must preserve the split.

Budget reservation makes that priority meaningful before a bucket is exhausted. The bot needs write capacity for cancellations and capacity in the relevant bucket for state checks. Batching does not create a separate account budget, and access to batch endpoints is not a substitute for token accounting. Bounded retries complete the design by preventing failed work from competing indefinitely with protective calls.

Hidden token costs that silently drain the budget

As of June 11, 2026, pre-V2 order endpoints cost significantly more than their V2 equivalents. Old code can therefore spend the write allowance much faster than a capacity plan based on V2 calls predicts.

High-volatility events expose a different problem. REST provides snapshots, and its rate limits do not scale with market volatility. During Fed decisions, debate nights, and playoff games, order books can change in seconds. A bot polling at its normal rate can act on stale data before it encounters a 429, so the absence of rate-limit errors does not establish data freshness.

Integer price and count fields were replaced by string fixed-point fields, with old fields removed in 2026 Q1. Examples include yes_bid_dollars containing "0.4200" and count_fp containing "10.00". Fill responses lost client_order_id in March 2026, and the deprecated available_on_brokers field was removed from REST event responses in August 2026 after it stopped being populated. Code that depends on those removed fields is broken, even if the surrounding request succeeds.

Handling 429s without a Retry-After header

Kalshi’s rate-limit documentation states that 429 responses do not currently include Retry-After or X-RateLimit-* headers. The bot must therefore estimate recovery from its tier’s refill rate, the intended operation’s cost, and its account-wide consumption. That estimate supplies the basis for a retry window rather than a guarantee that capacity will remain available. Other workers may be drawing from the same bucket.

Exponential backoff should space repeated attempts, with a bounded number of retries. The timing must reflect the bucket’s recovery, since a 429 adds no penalty that justifies an arbitrary long wait. A 429 on a write means the exchange left that request unprocessed. The bot’s retry path must check state before resubmitting.

Timeout ambiguity makes this discipline especially important. A timeout can be followed by a successful fill, while the March 2026 removal of client_order_id from Fill responses invalidates reconciliation that expects that field there. Hard guardrails belong between the model and the API, including a maximum price, maximum contract counts per order and per day, and a daily loss limit. Every order needs a unique client_order_id, with order groups as a further backstop against runaway execution.

Testing 429 handling and state correctness before going live

Tests of how the bot handles rate limits must track state through a sequence as well as check single error responses. Budget exhaustion, a failed attempt, a later fill, and reconciliation need to produce a correct account view together. A test that only establishes that the bot pauses after a 429 does not establish that its next action is safe. Recovery is complete only when timing and state handling agree.

The demo environment mirrors the production API and uses simulated money. It is the right place to test authentication, reconciliation, cancellation, and maximum-exposure scenarios without affecting live credentials or production rate-limit budgets. A safe test suite that needs no credentials should run on its own on every commit. Live tests against the demo environment should run only with explicit opt-in.

The demo environment does not provide deliberate fault injection at chosen points in a sequence. A stateful simulator gives that control by keeping order-book, fill, and account state from one call to the next. It can inject a 429, a sequence of 503s, or a timeout followed by a successful fill. Repeatable sequences let the tests establish whether backoff and reconciliation work together.

The structural barrier tiers create for new bot builders and how to navigate it

Volume-share thresholds create a real bootstrapping problem. Market making and data-intensive strategies may need higher throughput before they have accumulated the volume required to earn it. The constraint binds hardest when the bot is new and least proven. That structural limitation persists even with more workers.

The immediate response is to claim Advanced through the free self-serve call. The recent bulk-cancellation endpoint is also a concrete tool for protective traffic. Its place in the design remains subject to the same account-wide budget discipline as other operations.

The strategy should nevertheless fit Basic or Advanced throughput first. Those tiers can handle event-driven and medium-frequency approaches, but the bot must make good use of its allowance. True high-frequency trading is structurally impractical at any current tier. Designing toward it without the volume needed for upper tiers leads toward repeated budget exhaustion.

What to verify in the changelog before any production deployment

The Kalshi API changelog makes clear that capacity planning is an ongoing task. Its October 2026 entries cover the balance-bucket split, MCP portfolio grants, schema corrections across the Predictions and Margin specifications, FIX mass-cancel behavior, and margin market funding parameters. Those changes affect how requests are scheduled, permissions, generated types, how cancellations work, and assumptions about the product. A deployment review must therefore check the parts of the API the bot uses.

Subscribing to the RSS feed at /changelog/rss.xml is the minimum viable drift-monitoring practice. Before deployment, check whether an endpoint now uses a different bucket or has a different token cost. Check whether a consumed field has been renamed, type-changed, or removed. Also check whether a dependency has moved out of beta, since beta endpoints can change without notice while production endpoints are expected to stay more stable.

If the strategy touches perpetual futures, the review must cover the margin product’s separate REST, WebSocket, and FIX surfaces and its per-engine collateral model. Those distinctions can affect the bot’s failure modes even when its basic retry logic is sound. Rate-limit engineering is therefore not a one-time configuration exercise. It is the continuing discipline of keeping traffic, recovery, and state correctness aligned with the API the bot will actually call.