pykalshi

What it is

A third-party Python client for Kalshi, written for the case the generated official SDK does not cover: a program that has to stay connected. It is MIT, one author, 125 stars, and it has the three dates a reader needs - last release 2.0.0 on PyPI on 2026-07-27, last commit on main on 2026-07-29, repository not archived.

What it adds over a generated REST client:

• WebSocket streaming with typed messages - tickers, order book snapshots and deltas, trades - consumed as an async iterator you can pattern-match on.
• A local order book. OrderbookManager applies the deltas and hands back the current book, which is the piece every market-making script otherwise writes badly once.
• Automatic retries with exponential backoff on rate limits and transient errors, and typed exceptions - InsufficientFundsError, RateLimitError, KalshiAPIError with status and error code - instead of a generic HTTP failure.
• Domain objects. Market, Order and Event carry methods: order.cancel(), order.amend(price_dollars=...), order.decrease(...), order.wait_until_terminal(), market.get_orderbook().
• pandas and Jupyter. .to_dataframe() on any list result, including candlesticks and order books, and rich HTML rendering of markets, orders and positions in a notebook.
• A bundled web dashboard behind the [web] extra - FastAPI and uvicorn - for browsing markets and watching a portfolio locally. The README presents it as a development tool and a reference implementation rather than a product.

Five runtime dependencies: httpx, pydantic, cryptography, python-dotenv and websockets.

Availability

The package installs anywhere pip works and needs Python 3.9 or newer. Reads of public market data need no account.

Trading needs Kalshi credentials, and who may hold a funded Kalshi account is a question about the exchange - see kalshi. The library grants no access and blocks none, so the flags here are the exchange's: its reach, and the identity check every Kalshi account passes before an order goes through.

Pricing

Free, MIT-licensed, nothing metered and nothing to buy. Kalshi does not charge for API access either. Trading fees are the exchange's and are on its card.

Markets & resolution

The client resolves nothing. Orders placed through it rest on Kalshi's book and settle in dollars against the exchange's determination.

Two data-model details this library handles explicitly, and they are the ones that catch people. Prices are cents on the wire and the library exposes dollar-denominated fields (yes_price_dollars, price_dollars) beside them. And direction on Kalshi has two vocabularies: the legacy action-and-side pair, which the README notes means different things on orders than on fills and which Kalshi has deprecated, and the book_side / outcome_side pair it prefers. Both map onto the same wire body here, which is convenient and is also two ways to write the same bug.

Integrations

Nothing beyond Python. No CLI, no MCP server, no bot framework - the examples directory carries a momentum bot as a sample, not as a product. The optional extras are [dataframe] for pandas and [web] for the local dashboard.

It speaks to kalshi-api and nothing else.

Limitations

It is one person's library. 125 stars, one open issue, and no organisation behind it. That is not a criticism of the code, which is more carefully built than most of this category; it is the risk you are taking, and the mitigation is that it is MIT and readable.

Not full API coverage, by its own admission: the comparison table in the README gives that column to the official generated client. If you need an endpoint the author has not wrapped, you are dropping to HTTP.

Unofficial, so it tracks the API at one remove. Kalshi publishes SDK releases weekly against its OpenAPI specification; a third-party client learns about a change when something breaks.

No paper mode. There is no simulator: an order is a real order. Kalshi's own demo environment is the closest thing, and wiring this client to it is your job.

The automatic retry can place an order twice. In the 2.0.0 source, _request retries every method, POST included, on a timeout, a connection error, a 429 and a 5xx - by default three retries, with a 10-second timeout per attempt. place_order sends a client_order_id only if you pass one; unlike a subaccount transfer, which gets a fresh UUID when you leave the key out, an order gets none. An order that reached Kalshi but timed out on the way back is then sent again as a new order. Pass your own client_order_id on every order, which its docstring describes as an idempotency key, or set max_retries=0 and reconcile yourself. Why your bot gets throttled covers the retry side of this.

Nothing here has been run by us against a funded account - no order placed, no stream held open, no retry observed.

Alternatives

kalshi-python-sync is Kalshi's current official Python SDK: complete, released weekly, REST only, proprietary, and Python 3.13 or newer. kalshi-python is the deprecated package that came before it.

ccxt and pmxt reach Kalshi as one venue among several, if you would rather write one integration than the best one.

kalshi-api is the underlying API, which is plain HTTP and needs no client at all if all you want is a price.