By Kalshi View Editorial Team · Updated 2026-07-17

Real photo by Rob Wingate / Unsplash, used under the Unsplash License.

Kalshi API Rate Limits & Tiers: Current Token Budgets

This page was rechecked against Kalshi's official API documentation on July 17, 2026. The old rule of thumb that standard access is “about 10 requests per second” is no longer an accurate description of the published system. Use the live account and endpoint-cost endpoints in production rather than hard-coding this article's table forever.

Current Kalshi API tiers and budgets

Kalshi publishes the following per-second token refill rates. Read and write budgets are independent: exhausting one does not mean the other is also empty.

The final two columns are calculations for an endpoint at the documented default cost of 10 tokens: for example, Basic read capacity is 200 ÷ 10 = 20 calls per second at steady state. They are not separate limits published by Kalshi. An endpoint that costs 2 tokens can be called five times as often as a 10-token endpoint, assuming no other traffic consumes that bucket.

How tier qualification works

• Basic: complete account signup.
• Advanced: complete Kalshi's Advanced API application.
• Premier, Paragon, and Prime: Kalshi says qualification criteria will be published later.

Kalshi also says it may adjust a member's tier, including downgrading higher tiers after prolonged inactivity. A member can request an upgrade through support with a description of the use case. Do not promise yourself a particular tier based on funding level or trading volume; the current public page does not make those claims.

Token cost matters more than call count

Most authenticated requests currently cost 10 tokens, but several operations are cheaper. The API reference identifies exceptions, and Kalshi exposes a public endpoint that lists all non-default costs:

GET /trade-api/v2/account/endpoint_costs

The response includes default_cost and an endpoint_costs array with method, path, and token cost. That makes it safer to load costs during startup than to maintain a handwritten list. The endpoint currently documents a default cost of 10.

Inspect the limits assigned to the account

An authenticated client can query:

GET /trade-api/v2/account/limits

The current response model returns:

• usage_tier — the account's assigned API tier;
• read.refill_rate and write.refill_rate — tokens added per second;
• read.bucket_capacity and write.bucket_capacity — maximum tokens each bucket can hold.

Use these values as runtime configuration. A client that merely assumes “Advanced means 300/300” cannot detect an account-level change or a future documentation update.

Write bursts and the Basic-tier exception

For tiers above Basic, the write bucket can hold two seconds of its per-second budget. Traffic below the steady rate builds temporary headroom, which an event-driven client can spend in a burst. The bucket continuously refills and requests drain their endpoint cost.

Basic is the exception: its write bucket holds one second of budget, so there is no accumulated two-second write burst. In either case, a request is accepted again as soon as the affected bucket contains enough tokens; Kalshi documents no separate enforced cooldown.

Read the returned bucket_capacity instead of implementing the two-second rule as an eternal constant.

What happens on HTTP 429

When a bucket does not have enough tokens, Kalshi returns 429 Too Many Requests with an error body indicating too many requests. The rate-limits page says these responses currently do not include Retry-After or X-RateLimit-* headers.

A resilient client should:

1. identify whether the failed operation belongs to the read or write queue;
2. pause that queue without unnecessarily freezing the other bucket;
3. retry with bounded exponential backoff and random jitter;
4. preserve idempotency and client order IDs on write retries;
5. log endpoint, token cost, attempt count, and response status;
6. stop retrying after a defined deadline instead of creating an infinite request storm.

A fixed “sleep one minute” is not supported by the current docs, and immediately retrying every failed request can amplify the overload.

REST polling versus WebSocket streaming

For live order books, trades, market status, and fills, Kalshi provides an authenticated WebSocket API. Streaming changes is usually a better architecture than repeatedly downloading snapshots, but it is not “unlimited.” Kalshi's API changelog says WebSocket connections per user are limited by usage tier, with a default beginning at 200 and increasing with API tier.

The current rate-limits page does not publish a complete WebSocket tier matrix. Therefore this guide does not invent one or claim that WebSocket connections share the REST read bucket. Treat REST token budgets and WebSocket connection/subscription behavior as separately documented controls.

Implementation checklist for a production client

1. Load account limits: fetch /account/limits after authentication.
2. Load non-default costs: fetch /account/endpoint_costs and fall back to its returned default.
3. Keep two schedulers: meter read and write work independently.
4. Reserve write headroom: do not let low-priority maintenance calls consume all capacity needed for order management.
5. Use WebSockets for change feeds: maintain snapshots plus deltas rather than polling every watched market at a fixed high rate.
6. Back off on 429: apply jitter, caps, and a retry deadline.
7. Test batch arithmetic: count each batch item by its endpoint cost.
8. Reconcile periodically: refresh limits and costs so a long-running service notices changes.
9. Exercise failure paths in demo: verify dropped connections, stale snapshots, retry idempotency, and throttling behavior before production.

Frequently asked questions

What are Kalshi's current API rate limits?

Kalshi publishes per-second token budgets, not one universal requests-per-second number. Current read/write budgets are Basic 200/100, Advanced 300/300, Premier 1,000/1,000, Paragon 2,000/2,000, and Prime 4,000/4,000 tokens per second.

How many requests per second can Kalshi Basic tier send?

For an endpoint at the current default cost of 10 tokens, Basic tier has a steady-state ceiling of 20 read requests or 10 write requests per second. Cheaper endpoints can support more requests; batch items are charged individually.

Do Kalshi batch endpoints save rate-limit tokens?

No. Kalshi documents that every item in a batch is billed separately. A batch of 25 default-cost order creates costs 250 write tokens, while 25 cancellations at 2 tokens each cost 50.

What does GET /account/limits return?

The authenticated endpoint returns usage_tier plus read and write objects. Each bucket includes refill_rate in tokens per second and bucket_capacity, the maximum tokens the bucket can hold.

What should a client do after a Kalshi 429?

Treat read and write buckets independently, pause the affected queue, and retry with exponential backoff plus jitter. Kalshi documents that 429 responses currently omit Retry-After and X-RateLimit-* headers, so clients must pace retries themselves.

Are WebSocket connections covered by the REST token budgets?

The published token table describes authenticated API request budgets. Kalshi's changelog separately says WebSocket connections per user are limited by usage tier, with a default beginning at 200 and increasing by tier; it does not publish the full WebSocket tier matrix on the rate-limits page.

Technical and educational information only. API behavior, limits, endpoints, and eligibility can change. Query the live account endpoints and check Kalshi's official documentation before relying on any value in production. Kalshi View is independent and is not affiliated with Kalshi Inc.