DEV Community: DeskBot

Why I built DeskBot as local Kalshi desk automation (and a quick Capital vote ask)

DeskBot — Sat, 31 Oct 2026 16:33:22 +0000

I'm Joshua, solo maker of DeskBot Multi15 — a Mac/Windows desktop app that automates Kalshi desk workflows locally, using the trader's own API key. Keys stay on your machine.

What it is

Local automation for Kalshi desk workflows (not a hosted black box)
Your own API key
$1 first month, then $19.99/mo (not a free trial)
Store download is Multi15

Why local

Prediction-market tooling often wants your keys in the cloud. I wanted the opposite: run on your Mac/Windows, keep credentials local, and stay honest about risk.

Capital this week

DeskBot is in this week's AI Tools Capital vote (closes Sunday morning ET). If the local-first angle resonates, an upvote helps a solo maker a lot.

Product: deskbot.store

Trading involves full risk of loss. Not affiliated with Kalshi.

Kalshi API Rate Limits and WebSockets: A Bot Builder's Guide

DeskBot — Sat, 31 Oct 2026 13:18:12 +0000

If you are building a bot for Kalshi's 15-minute crypto markets, the two API details that decide whether it works are the rate limits and the WebSocket feed. Get them wrong and your bot either gets throttled with 429 Too Many Requests at the exact moment a market moves, or it trades on an order book that stopped updating 20 seconds ago. This guide covers how Kalshi's token-bucket limits work, how to budget a bot against them, and how to use the WebSocket API so you poll less and see more. Everything here was checked against docs.kalshi.com on October 23, 2026.

New to the markets themselves? Start with Kalshi 15-minute markets explained and the Kalshi API tutorial in Python, then come back here.

How Kalshi rate limits work: tokens, not request counts

Kalshi does not give you "N requests per minute." Every authenticated request costs tokens, and your account tier sets a budget: how many tokens per second refill into your balance. Most requests cost the default of 10 tokens. Some cost less; for example, Kalshi's docs list a batch cancel at 2 tokens per order. The authoritative list of non-default costs is the GET /account/endpoint_costs endpoint, so a careful bot reads it rather than hard-coding numbers.

Your sustained rate for any endpoint is simply:

sustained requests per second = budget Ã· cost

Two separate buckets: Read and Write

You have two independent budgets:

Read: GET endpoints (markets, order books, positions, fills) and anything not routed to Write.
Write: placing, amending and cancelling orders, order groups, and the RFQ quote flow.

The split is by what the request does, not how it is sent. REST and FIX requests drain the same buckets. Polling the order book too hard therefore cannot block your order placement, but it can stop you reading positions and fills. And GET /portfolio/balance sits in its own small bucket: once per second on the Basic and Advanced tiers. Kalshi's own advice is to react to fills and settlements (for example through the fills WebSocket channel) instead of polling balance.

The tier table

Per-second token budgets for event contracts (predictions), from Kalshi's rate-limit page:

Tier	Read budget	Write budget	Orders/sec at 10 tokens
Basic	200	100	10
Advanced	300	300	30
Expert	600	600	60
Premier	1,200	1,200	120
Paragon	2,400	2,400	240
Prime	4,800	4,800	480
Prestige	12,000	9,600	960

Basic is what you get at signup. Advanced is available by calling Kalshi's "Upgrade Account API Usage Level" endpoint. The higher tiers are granted automatically from trading volume (your trailing 30-day volume as a share of exchange volume, reviewed daily) or assigned by Kalshi. You can see your current tier and grants with GET /account/limits.

Bursting: why an idle bot can fire a block of orders

Each budget is a token bucket that refills continuously; there are no fixed windows or per-second resets. Bucket size matters:

Basic and Advanced Read buckets, and Write buckets above Basic, hold three seconds of budget. After three quiet seconds the bucket is full and you can spend up to 3Ã— your per-second budget at once.
The Basic Write bucket holds only one second of budget. Idle time banks nothing beyond that.

Worked example (Basic tier): your Write bucket refills at 100 tokens/second and holds 100. You can send 10 default-cost orders in one instant, then 10 per second after that. On Advanced, the Write bucket refills at 300/second and holds 900, so after three idle seconds you could send 90 orders at once, then 30 per second.

For a 15-minute crypto bot this is usually plenty. A bot trading BTC, ETH, SOL and XRP 15-minute markets that places one entry and maybe one cancel per market per window needs a handful of writes every 15 minutes. You hit the limit only with loops that re-quote or cancel-and-replace on every tick.

Batch endpoints do not save tokens

This catches many bot builders. Batch requests cost the same as the individual calls: Kalshi's docs give 25 batched order creates as 25 Ã— 10 = 250 tokens. Worse, the whole batch must fit in the bucket at once. On Basic, where the Write bucket holds 100 tokens, a 25-order create batch needs 250 tokens and will be rejected whole, every time. Batching helps with round trips, not with your budget.

What a 429 looks like and how to handle it

A throttled request returns HTTP 429 with the body {"error": "too many requests"}. Per the docs, 429s currently carry no Retry-After or X-RateLimit-* headers and there is no penalty or cooldown: the next request succeeds once the bucket refills enough. Kalshi recommends exponential backoff. In practice, a good bot also:

Budgets itself on the client side, keeping a local token counter that mirrors the server's, so it rarely sees a 429 at all.
Gives writes priority. If a cancel is waiting, it goes before a nice-to-have refresh.
Never retries an order blindly. A timeout is not a rejection. Send a client_order_id and check your open orders before you re-send, or you risk a duplicate position.

Exchange shards and per-shard Write budgets

Kalshi runs prediction markets across exchange shards, and each market reports an exchange_index. When we pulled an open BTC 15-minute market (series KXBTC15M) from the public markets endpoint this evening, it reported exchange_index: 2. That matters for budgets: a single REST order create, cancel, decrease or amend that targets shard 1 or higher draws from a Write bucket scoped to that shard, and each shard's bucket carries your full tier budget. Shard 0 bills your unscoped Write bucket. Auto-routed traffic (exchange_index: -1, or omitted when market_ticker is given) is billed to every shard's bucket. Batch creates and cancels always bill the unscoped bucket.

The practical takeaway: if your bot trades markets on more than one shard, passing the market's own exchange_index on single orders keeps each shard's traffic in its own budget instead of charging all of them.

Use the WebSocket API instead of polling

The fastest way to burn your Read budget is to poll the order book of four markets every 250 ms: that is 16 requests and 160 tokens per second, most of your 200-token Basic Read budget, for data that often hasn't changed. Kalshi's WebSocket API pushes changes to you instead: one subscription replaces that whole polling loop, and your Read budget is left for the occasional REST call.

Connecting

The production WebSocket endpoint is wss://external-api-ws.kalshi.com/trade-api/ws/v2 (demo: wss://external-api-ws.demo.kalshi.co/trade-api/ws/v2; the older shared hosts are still supported). The handshake is authenticated with the same three headers as REST: KALSHI-ACCESS-KEY, KALSHI-ACCESS-TIMESTAMP (milliseconds) and KALSHI-ACCESS-SIGNATURE. The signature is over timestamp + "GET" + "/trade-api/ws/v2", signed with your Ed25519 key (Kalshi's recommended type) or with RSA-PSS SHA-256 for an RSA key.

Channels that matter for a 15-minute bot

orderbook_delta (private): an orderbook_snapshot first, then incremental orderbook_delta messages for the markets you list.
ticker (public data): best yes bid/ask and last price updates.
trade: executions as they print.
fill and market_positions (private): your own fills and positions, which replace most portfolio polling.
market_lifecycle_v2: markets opening, closing and settling, which is how a bot knows the next 15-minute window exists without polling the markets list.

You subscribe by sending a command such as:

{"id": 1, "cmd": "subscribe",
 "params": {"channels": ["orderbook_delta"],
            "market_tickers": ["KXBTC15M-..."]}}

Each subscription gets a server-generated sid. You can add or remove markets with update_subscription, and ask for a fresh snapshot with its get_snapshot action without changing the subscription.

Sequence numbers: how to know your book is real

This is the part most homemade bots skip. Every snapshot and delta carries a seq, and per Kalshi's docs seq counts messages on one subscription only. If you see a gap (seq 41 followed by seq 43), you missed a message and your local book is wrong. Don't keep trading on it: request a new snapshot and rebuild. Messages also carry an exchange clock, which is the same on every connection. That lets you match updates across two redundant connections. Clocks skip values and are not comparable across markets, so always use seq to detect gaps.

Two more details worth building in:

Kalshi's book lists bids on both sides. The snapshot has YES bids and NO bids. The YES ask is $1 minus the best NO bid. (Our guide to reading the Kalshi order book walks through it.)
Keep-alive. Kalshi notes that Python's websockets library answers ping/pong frames automatically; other libraries may need you to handle them. Either way, plan for disconnects: on reconnect, re-sign, re-subscribe and wait for a fresh snapshot before trading.

A sane budget for a four-market 15-minute bot

Here is a design that fits comfortably inside the Basic tier:

One WebSocket connection subscribed to orderbook_delta and ticker for the current BTC, ETH, SOL and XRP 15-minute markets, plus fill, market_positions and market_lifecycle_v2.
REST reads only on events: when a new window opens (lifecycle message), read that market's details once. That is a few reads per 15 minutes, not per second.
Writes: at most a few per market per window, such as one limit order and an occasional cancel. Even 20 writes in a burst spread over a couple of seconds stays under 100 tokens/second.
A local token counter for both buckets, with writes taking priority and backoff on any 429.

Rate limits and data freshness are only half the job, though. The other half is whether a trade is worth taking after fees. At a 50Â¢ price Kalshi's trading fee works out to about 2Â¢ per contract after rounding, and near 90Â¢ a single loss wipes out many small wins. See Kalshi fees and breakeven win rate for the math.

Build it or start from one that's already built

Everything above is buildable in a weekend if you enjoy it, and the Kalshi docs are good. If you'd rather see a working bot first, DeskBot for Kalshi ($1 the first month, then $19.99/month) runs on your own Windows or Mac machine with your own Kalshi API key, so the market feed and order plumbing are already done. You choose the settings and decide whether it trades.

FAQ

What is the Kalshi API rate limit?

It's token-based. Most requests cost 10 tokens. The Basic tier refills 200 Read tokens and 100 Write tokens per second, so about 20 reads and 10 order actions per second at the default cost. Higher tiers raise both.

Does the Kalshi API return a Retry-After header on 429?

Not currently. Kalshi's docs say 429 responses have no Retry-After or X-RateLimit-* headers and no cooldown. Back off exponentially and retry once the bucket has refilled.

Do Kalshi batch orders reduce rate-limit usage?

No. Each item is billed separately, and the whole batch must fit in your bucket at once. On Basic, a 25-order create batch (250 tokens) is larger than the 100-token Write bucket and will be rejected.

How do I get a higher Kalshi API tier?

Advanced is self-serve through the API usage-level upgrade endpoint. Expert and above are granted automatically from your 30-day trading volume share, reviewed daily, or assigned by Kalshi.

What is the Kalshi WebSocket URL?

wss://external-api-ws.kalshi.com/trade-api/ws/v2 for production and wss://external-api-ws.demo.kalshi.co/trade-api/ws/v2 for demo. The handshake is signed like a REST request, over the path /trade-api/ws/v2.

How do I know if I missed an order book update?

Check seq on every message of a subscription. A gap means you missed a message, so request a fresh snapshot and rebuild your local book before trading.

Is a faster bot a profitable bot?

No. Good API handling keeps a bot from acting on stale data or getting throttled, but it creates no edge by itself. Fees and spread still have to be beaten, and many strategies don't beat them.

Try DeskBot for $1 â€” first month $1, then $19.99/month, cancel anytime. Card required; it renews at $19.99/month unless you cancel.

Risk: Trading on Kalshi or Polymarket involves risk, and you can lose money, including your entire stake. There are no guaranteed profits or returns, and past or paper results do not predict future results. This is educational, not financial advice. DeskBot is independent software and is not affiliated with, endorsed by, or sponsored by Kalshi or Polymarket. API details were taken from Kalshi's published documentation on October 23, 2026. Limits and endpoints change, so check docs.kalshi.com before you build.

Originally published on the DeskBot blog.

Kalshi API Keys and Authentication: How Request Signing Works

DeskBot — Sat, 31 Oct 2026 03:14:55 +0000

Every Kalshi trading bot starts with the same piece of plumbing: an API key and a signed request. Public market data needs no key. The moment your code reads your balance or places an order, Kalshi wants three headers and a cryptographic signature on every call. This guide explains how Kalshi API keys work, which key type to pick, exactly what string gets signed, how scopes and sub-account binding limit what a key can do, and the mistakes that produce a 401 at 3 a.m. Everything below was checked against docs.kalshi.com on October 27, 2026.

Public endpoints vs. authenticated endpoints

Kalshi's Trade API v2 splits into two kinds of calls:

Public market data such as /markets, /events, /series and order books. You can read these without a key, which is why most tutorials start there.
Account endpoints such as /portfolio/balance, /portfolio/positions, /portfolio/fills and order placement. These require a signed request tied to an API key on your account.

The recommended production base URL is https://external-api.kalshi.com/trade-api/v2, and the demo environment uses https://external-api.demo.kalshi.co/trade-api/v2. Kalshi says the key process is the same on both. Keys are per environment, though: a demo key only works against demo hosts, and a production key only works against production hosts. (Our demo environment guide covers switching between the two.)

Production and demo hosts

Environment	REST base URL (recommended)	REST (also supported)	WebSocket (recommended)
Production	`https://external-api.kalshi.com/trade-api/v2`	`https://api.elections.kalshi.com/trade-api/v2`	`wss://external-api-ws.kalshi.com/trade-api/ws/v2`
Demo	`https://external-api.demo.kalshi.co/trade-api/v2`	`https://demo-api.kalshi.co/trade-api/v2`	`wss://external-api-ws.demo.kalshi.co/trade-api/ws/v2`

Source: docs.kalshi.com, API Environments and Endpoints, checked October 29, 2026. The external-api hosts are dedicated to the Trade API; the older shared hosts stay supported for existing clients. Despite the elections subdomain, the production API covers all Kalshi markets, not only election markets.

The host does not change the signature. Whichever host you call, you sign the same path from the API root, for example /trade-api/v2/portfolio/orders. Moving from api.elections.kalshi.com to external-api.kalshi.com means changing the base URL only, not your signing code.

How to create a Kalshi API key

Most people create a key in the web app:

Log in and open Profile Settings (kalshi.com/account/profile).
Find the API Keys section and click Create New API Key.
Pick the key type. Ed25519 is the default; choose RSA only if your client library supports RSA-PSS and nothing else.
Save the private key right away. Kalshi downloads it as a .txt file and does not keep a copy. Once the page closes, you cannot get it back; you would have to create a new key.

You will end up with two things: a Key ID (safe to put in a config file) and a private key in PEM format (treat it like a password, because it is one).

There is a second route for advanced users. You can generate your own key pair with OpenSSL and register only the public half, so the private key never leaves your machine. Through the API, POST /trade-api/v2/api_keys registers a public key and POST /trade-api/v2/api_keys/generate returns a new pair. Kalshi's reference notes that creating keys through the API is limited to Premier and Market Maker API usage levels; other accounts get a 403 and use the web page instead.

Ed25519 or RSA: which key type?

	Ed25519	RSA (2048-bit)
Default in the web app	Yes	No
Signature scheme	Ed25519 (RFC 8032), 64-byte signature	RSA-PSS, SHA-256, MGF1-SHA-256, salt = digest length
Private key PEM header	`-----BEGIN PRIVATE KEY-----`	`-----BEGIN RSA PRIVATE KEY-----` (PKCS#1)
When to choose it	New code; Kalshi recommends it	Older clients that only do RSA-PSS, including Kalshi SDK versions before 3.31.0

One trap: the PEM header alone does not tell you the type, because RSA keys saved as PKCS#8 also start with BEGIN PRIVATE KEY. Load the key with a crypto library and check the parsed object's type, not the text of the first line.

The three headers on every authenticated request

KALSHI-ACCESS-KEY: your Key ID.
KALSHI-ACCESS-TIMESTAMP: the current time in milliseconds since the Unix epoch.
KALSHI-ACCESS-SIGNATURE: the base64-encoded signature of the request.

Exactly what gets signed

The message is three pieces glued together with no separators: timestamp + HTTP method + path. Query parameters are not part of it; strip the ? and everything after it before signing.

A worked example. Say your code wants your open positions at 1,761,580,800,000 ms:

Full URL: https://external-api.kalshi.com/trade-api/v2/portfolio/positions?limit=100
Method: GET
Path to sign: /trade-api/v2/portfolio/positions (the ?limit=100 is dropped)
Message: 1761580800000GET/trade-api/v2/portfolio/positions

Sign those bytes with your private key, base64-encode the result, and send it as KALSHI-ACCESS-SIGNATURE alongside the same timestamp. Note the path starts at /trade-api/v2, not at the host and not at /portfolio.

A minimal Python signer

This sketch uses the widely used cryptography and requests packages and handles both key types. It is written for this article as an illustration; test it on the demo host before pointing it at real money.

import base64, time, requests
from urllib.parse import urlparse
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import ed25519, padding, rsa

BASE = "https://external-api.kalshi.com/trade-api/v2"
KEY_ID = "your-key-id"                      # from Profile Settings
with open("kalshi_private_key.txt", "rb") as f:
    PRIVATE_KEY = serialization.load_pem_private_key(f.read(), password=None)

def sign(message: bytes) -> str:
    if isinstance(PRIVATE_KEY, ed25519.Ed25519PrivateKey):
        sig = PRIVATE_KEY.sign(message)
    elif isinstance(PRIVATE_KEY, rsa.RSAPrivateKey):
        sig = PRIVATE_KEY.sign(
            message,
            padding.PSS(mgf=padding.MGF1(hashes.SHA256()),
                        salt_length=padding.PSS.DIGEST_LENGTH),
            hashes.SHA256())
    else:
        raise ValueError("unsupported key type")
    return base64.b64encode(sig).decode()

def get(path: str, **params):
    url = BASE + path
    ts = str(int(time.time() * 1000))
    signed_path = urlparse(url).path          # no query string
    headers = {
        "KALSHI-ACCESS-KEY": KEY_ID,
        "KALSHI-ACCESS-TIMESTAMP": ts,
        "KALSHI-ACCESS-SIGNATURE": sign((ts + "GET" + signed_path).encode()),
    }
    return requests.get(url, headers=headers, params=params, timeout=10)

print(get("/portfolio/balance").json())

Notice the key type is detected from the parsed key object, which avoids the PEM-header trap above. For a POST the same rule applies: sign timestamp + POST + path; the JSON body is not part of the signed string.

Scopes: give a key only the access it needs

When you register a key through the API, the request accepts an optional scopes list. Leave it out and the key gets full access (read and write). The allowed values in Kalshi's reference are:

read and write, the broad scopes. If you grant write you must also grant read.
Narrower child scopes such as read::portfolio_balance, write::trade and write::transfer, plus block-trade and FCM-specific ones. Child scopes can be granted without their parent.

The practical use: a dashboard that only displays your balance does not need the power to trade or move funds. A trading bot needs to trade, but it has no reason to hold write::transfer. The smaller the scope, the less a leaked key can do.

Binding a key to one sub-account

The same request takes an optional subaccount number from 0 to 63. A key bound to a sub-account can only act inside that sub-account. That is a clean way to give an automated strategy its own pot of money: whatever the bot does, it cannot touch positions or cash outside its sub-account. (FCM members have a separate fcm_subtrader_id option, which cannot be combined with subaccount.)

Keeping the private key safe

Never commit it to git. Keep it outside your repo and load it from a path or a secrets manager. Add the filename to .gitignore anyway.
Lock down file permissions on macOS and Linux (chmod 600), so other users on the machine cannot read it.
Never paste it into chats, support tickets, screenshots or AI tools. Your Key ID alone is harmless; the private key is the secret.
One key per tool. If you run a dashboard and a bot, give each its own key so you can revoke one without breaking the other.
Revoke and replace a key in Profile Settings the moment you suspect it leaked. A new key takes a minute to create.

Common authentication errors and their causes

Symptom	Usual cause
`401` on every call	Timestamp in seconds instead of milliseconds, or the wrong Key ID for the private key
`401` only on calls with filters	Query string included in the signed path
`401` that comes and goes	Computer clock drifting; turn on automatic time sync
`401` with an RSA key	PKCS#1 v1.5 padding used instead of PSS, or the wrong salt length
Works on demo, fails on production	Demo key used against the production host (or the reverse)
`403` on an order	Key scoped without trade permission, or bound to a different sub-account
`403` creating a key by API	Account below the Premier API usage level; use the web page

Once auth works, the next limit you will meet is request volume; our rate limits and WebSocket guide covers that, and the Python API tutorial walks through reading markets and placing orders.

Or use software that already handles signing

Writing your own signer is a good way to learn how Kalshi's API works. If you would rather start from finished software, DeskBot for Kalshi is a desktop app that runs on your own computer and trades Kalshi's 15-minute markets on your own account through your own API key; the key stays on your machine. It starts in paper mode until you switch a market live, and you choose the limits. The current offer is Try DeskBot for $1: first month $1, then $19.99/month, cancel anytime. It does not guarantee profits or win rates.

FAQ

Do I need an API key to read Kalshi market prices?

No. Public market data such as markets, events and order books can be read without a key. You need a key for anything tied to your account: balance, positions, fills and orders.

Can I recover a lost Kalshi private key?

No. Kalshi does not store your private key. If you lose it, delete the old key in Profile Settings and create a new one.

Should I choose Ed25519 or RSA?

Ed25519 is Kalshi's default and recommendation. Choose RSA only if your client supports RSA-PSS and not Ed25519, such as Kalshi SDK versions before 3.31.0.

Are query parameters part of the Kalshi signature?

No. Sign timestamp + method + path, with everything from the ? onward removed. Including the query string is one of the most common causes of a 401.

What unit is KALSHI-ACCESS-TIMESTAMP in?

Milliseconds since the Unix epoch, sent as a string, and the same value you used in the signed message.

Can I stop a key from moving money?

Yes, when you register a key through the API you can pass a scopes list that leaves out write::transfer, and you can bind it to a single sub-account. Without a scopes list the key gets full read and write access.

Do I need to change my signing code if I switch Kalshi API hosts?

No. The signed path is the same on every host, for example /trade-api/v2/portfolio/orders. Moving from api.elections.kalshi.com to the recommended external-api.kalshi.com only changes the base URL.

Does a demo API key work on production?

No. Kalshi does not share credentials between environments. Demo keys only work against demo hosts and production keys only against production hosts.

Is DeskBot affiliated with Kalshi?

No. DeskBot is independent software. It uses Kalshi's public Trade API on the customer's own account.

Risk: Trading on Kalshi involves risk, and you can lose money. Nothing here guarantees profits, returns, win rates or income. This article explains API mechanics. It is not legal, tax or investment advice. DeskBot is independent software and is not affiliated with or endorsed by Kalshi. Sources, checked October 27, 2026: docs.kalshi.com API Keys guide (getting_started/api_keys) and the Create API Key reference (api-reference/api-keys/create-api-key); API Environments and Endpoints (getting_started/api_environments), checked October 29, 2026. APIs change, so check the current documents before you rely on any detail.

Originally published on the DeskBot blog. DeskBot is a desktop app that automates Kalshi 15-minute crypto trading on your own computer and account, with paper mode and daily loss limits: $1 for the first month, then $19.99/month (get DeskBot). Trading on Kalshi involves risk and you can lose money; no profits or returns are guaranteed. DeskBot is independent software and is not affiliated with or endorsed by Kalshi or Polymarket.