Kalshi API Rate Limits Explained (2026)
The Short Answer
Kalshi API rate limits are metered in tokens, not requests. Most calls cost 10 tokens, and your tier sets the refill rate: the entry-level Basic tier gives 200 read and 100 write tokens per second, which works out to 20 reads and 10 order actions per second. Reads and writes draw on separate buckets, there are seven tiers, and the step up to Advanced is one self-serve API call. Go over and you get a 429 with no penalty and no cooldown.
Almost everyone searching for Kalshi API rate limits wants a number shaped like "N requests per second". That number stopped existing on 23 April 2026, when Kalshi retired its per-second request scheme in favour of a token-cost model. Any article still quoting a flat request cap is describing a system that no longer runs.
Our complete Kalshi API guide covers this in a paragraph. Here is the deep version: how the buckets behave, what a request costs, how many markets you can poll on the entry tier, and the two billing traps that quietly gut a bot's throughput. Checked against Kalshi's official rate limits documentation in August 2026.
Key Takeaways
- Your sustained rate is budget divided by cost. Basic's 200 read tokens per second sounds like 200 requests; at the default 10 tokens per call it buys 20.
- Read and write are independent budgets, and Kalshi's perpetual futures (perps) are metered separately again, so an account trading both products runs four buckets. Batch endpoints bill every item and save nothing.
- A 429 carries no penalty, no cooldown and, at the time of writing, no
Retry-Afterheader. Back off exponentially anyway.
How Kalshi API Rate Limits Actually Work
Every authenticated request spends tokens from a bucket that refills continuously at your tier's budget, and the request goes through the moment the balance covers its cost. No fixed windows, no top-of-second reset: picture a tap filling a cup, not a counter that zeroes. Sustained throughput is budget divided by cost. The default cost is 10 tokens, but it varies: GET /account/endpoint_costs is the authoritative list of exceptions, and cancels bill 2.
The split follows the operation rather than the protocol. Write covers order placement, amends, cancels, order groups, the RFQ quote flow and block trade accepts; Read covers GET endpoints and everything else. A FIX order and a REST order both spend from Write, so a FIX session and a REST polling loop on one account compete for one budget. GET /account/limits returns your usage_tier, refill rate and bucket capacity.
The Seven Kalshi API Tiers
Two tiers you can reach on your own; the other five are earned or granted. The reads per second column is derived at the default 10 token cost.
| Tier | Read tokens/s | Write tokens/s | Reads/s at 10 tokens | How to get it |
|---|---|---|---|---|
| Basic | 200 | 100 | 20 | Complete signup |
| Advanced | 300 | 300 | 30 | Self-serve API call |
| Expert | 600 | 600 | 60 | 0.075% volume share |
| Premier | 1,000 | 1,000 | 100 | 0.125% volume share |
| Paragon | 2,000 | 2,000 | 200 | 0.25% volume share |
| Prime | 4,000 | 4,000 | 400 | 0.50% volume share |
| Prestige | 10,000 | 8,000 | 1,000 | 1.00% volume share |
Volume share means your trailing 30-day volume, counting both sides of every trade you are part of, divided by twice the previous calendar month's total exchange volume. The percentages in the table are the Earn thresholds, the figures you have to reach to gain the tier.
The Basic to Advanced step is really an order-entry upgrade: reads rise by half, writes triple. It carries no documented volume requirement, and Kalshi's rate limit documentation lists no charge for it, so no trading bot has a good reason to sit on Basic. Basic and Prestige are the only tiers where the two budgets diverge, Basic skewing toward reads and Prestige toward writes. Everything from Advanced to Prime is symmetric.
Kalshi API Requests Per Second: A Worked Example
Say you are on Basic: 200 read tokens per second at the default cost, so 20 requests per second sustained and 40 in a burst. How many markets that covers depends entirely on the endpoint. The markets list endpoint pages up to 1,000 results per call, returns bid, ask, last price and volume per market, and needs no authentication. So a Basic budget of 20 calls a second, at 1,000 markets a page, sweeps a large slice of the exchange every second. Size that against the live market count rather than against this article, because the sports contracts alone move the total around week to week.
Full depth is another matter. GET /markets/{ticker}/orderbook takes a single ticker and requires auth, so Basic buys 20 books per second. Watch 200 markets at depth and each sweep takes ten seconds, by which point your first book is stale. No tier fixes that gracefully; Prestige just does something wasteful faster. Subscribe over WebSocket instead, the architecture in our Kalshi trading bot guide. Two caveats: the rate limits page never mentions WebSocket, and the WebSocket docs expose an error for exceeding a subscription command rate limit without publishing the threshold.
One loose end on that unauthenticated markets endpoint. Kalshi's wording covers authenticated requests specifically and says nothing about anonymous ones, so whether those calls draw on your Read bucket is undocumented. Do not read the silence as a free lane. Authenticate, budget every call against your Read bucket, and avoid designing around an allowance that could close without notice.
Bursting, Batches, and Two Traps
Buckets have capacity as well as a refill rate, and unspent tokens accumulate up to that ceiling. Basic and Advanced Read buckets, and Write buckets above Basic, hold two seconds of budget: idle for two seconds and you can then spend double in a single burst before throttling back. Kalshi's own worked case is a Premier Write bucket refilling at 1,000 and holding 2,000, good for 200 orders at once and then 100 per second. The exception is easy to miss. Read buckets above Advanced, perps Read buckets and Basic-tier Write buckets hold only one second, so idle time banks nothing.
Trap one: batches save no tokens. Every item bills separately, so 25 batch-created orders cost 250 tokens, and the whole batch must fit in the bucket on arrival or all of it is rejected. Trap two is worse than a billing quirk: the legacy /portfolio/orders mutation and batch endpoints are gone. Kalshi escalated their token cost through May and June 2026, to five times the V2 equivalents on 1 June and ten times on 4 June, then deprecated them between 18 and 25 June, and calls now come back with Please switch to the V2 endpoints. They no longer appear in the live GET /account/endpoint_costs list either. A bot still posting to the legacy paths is not losing throughput; its orders are being refused. Move it to the current V2 order endpoints. Perps runs its own buckets, which never touch your event-contract budgets.
Kalshi Rate Limit 429: What Actually Happens
Run the bucket dry and Kalshi returns 429 Too Many Requests with the body {"error": "too many requests"}. That is the entire response: at the time of writing there is no Retry-After header and no X-RateLimit-* family, so the server tells you nothing about when to come back. The reassuring part is what does not happen. Kalshi documents no penalty and no cooldown: the bucket keeps refilling and your next request lands as soon as the balance covers it, about 50 milliseconds later for a read on Basic, or 100 for a write, since the two buckets refill at different rates. A 429 here is a busy signal, not a punishment. It is not licence to hammer the endpoint either, because Kalshi keeps discretion over account access.
Kalshi still tells you to apply exponential backoff, and it is right to. Without rate limit headers your client is flying blind, and a tight retry loop spends its whole refill on rejections instead of work. Catch the 429 and retry with a growing delay plus jitter. Start at roughly one refill interval, 50 milliseconds for reads on Basic or 100 for writes, double on each failure, cap at a second or two, and let the jitter stop a fleet of workers resynchronising into a thundering herd. Our Kalshi Python tutorial covers where that belongs in a client wrapper.
How to Move Up a Tier
Basic arrives with signup. Advanced is one call to the Upgrade Account API Usage Level endpoint, POST /account/api_usage_level/upgrade, self-serve and with no documented volume requirement. If you place orders, make that call today. Everything above is earned from volume or assigned by Kalshi at its discretion. Once a day Kalshi reviews your volume share on the definition given above. Qualifying grants the tier for 30 days, renewed by each daily review.
Every tier has a higher Earn threshold to gain it and a lower Keep threshold to hold it, so a quiet fortnight does not cost you the tier outright: it lapses when the grant expires. Kalshi does not publish the Keep figures alongside the Earn thresholds, so plan against the percentages in the table above. Kalshi can also adjust tiers at will, including downgrading after prolonged inactivity. Be realistic about the numbers, though. Expert, the first earned tier, wants a 0.075% volume share at the time of writing, which is far more trading than a hobby bot generates. Most developers will live on Advanced permanently, and 300 reads per second is ample once you are streaming. Chasing a tier is a bad reason to trade more, and none of this is trading advice.
Frequently Asked Questions
What are the Kalshi API rate limits?
Kalshi API rate limits work as a token budget rather than a request count. Every authenticated request spends tokens from a continuously refilling bucket, most endpoints cost 10 tokens, and your tier sets the refill rate. Reads and writes have separate budgets, from 200 read and 100 write tokens per second on the entry-level Basic tier up to 10,000 read and 8,000 write on Prestige at the time of writing. Check docs.kalshi.com/getting_started/rate_limits for current figures.
What are the Kalshi API limits on the free tier?
The entry tier, Basic, gives 200 read and 100 write tokens per second as of August 2026. At the default 10 tokens per request that is 20 read calls and 10 order actions per second. The Read bucket holds two seconds of budget, so after a quiet spell you can burst 40 reads at once. Kalshi's rate limit documentation lists no fee for any tier; confirm current terms with Kalshi before budgeting.
What are the Kalshi API tiers?
Seven: Basic, Advanced, Expert, Premier, Paragon, Prime and Prestige. Basic comes with signup, and Advanced is a self-serve call to POST /account/api_usage_level/upgrade that raises reads from 200 to 300 tokens per second and writes from 100 to 300. The five above are earned from your trailing 30-day volume share or assigned manually, with Expert starting at 0.075% as of August 2026. Kalshi revises these thresholds, so check docs.kalshi.com/getting_started/rate_limits before you plan around them.
What does a Kalshi rate limit 429 mean?
Your token bucket lacked the tokens to cover the request. Kalshi returns 429 Too Many Requests with the body {"error": "too many requests"} and, at the time of writing, no Retry-After or X-RateLimit headers. There is no penalty and no cooldown: the bucket keeps refilling and your next request succeeds once the balance covers the cost, roughly 50 milliseconds later for a read on Basic and 100 for a write, because the two buckets refill at different rates.
How many requests per second does the Kalshi API allow?
There is no fixed requests-per-second cap, because the limit is counted in tokens. Divide your tier's budget by the endpoint's cost. On the August 2026 tiers, at the default 10 token cost, that is 20 reads per second on Basic, 30 on Advanced, 100 on Premier and 1,000 on Prestige. Cancels cost 2 tokens and draw on the Write bucket, so Basic's 100 write tokens per second covers 50 cancels a second against 10 order placements.
Conclusion
The practical summary is short. Make the Advanced upgrade call, move any legacy order code onto the V2 endpoints, and subscribe over WebSocket instead of polling books. A 429 is a routine event: back off and carry on. Kalshi's design here is unusually forgiving, and most builders hit an architectural wall long before they hit the numbers. If you would rather not run a collector, Predictefy normalises this data across venues, and our guide to prediction market data sources covers the alternatives, including the ones that are not us.