kalshi-python

What it is

A Python client for Kalshi's trading API, generated automatically from Kalshi's own OpenAPI specification by OpenAPI Generator 7.15.0. It wraps the REST surface of the exchange in ten API classes and a convenience KalshiClient that stitches them together, and it handles the RSA request signing that Kalshi's authenticated endpoints require.

It is Kalshi's, and it is closed. Both halves matter. The PyPI package names Kalshi Support and support@kalshi.com as author, the generated specification carries the same contact, and the quickstart points at Kalshi's own documentation site - this is the exchange's package, not a community fork. But the repository its metadata names, Kalshi/exchange-infra, returns 404 to anyone outside the company, the wheel declares its licence as LicenseRef-Proprietary, and the only public artefact is the built package on PyPI. You can install it and you can read the generated Python that ships inside the wheel; you cannot see its history, file an issue against it, or send a patch.

The API classes are ApiKeysApi, CommunicationsApi, EventsApi, ExchangeApi, MarketsApi, MilestonesApi, MultivariateCollectionsApi, PortfolioApi, SeriesApi and StructuredTargetsApi. In practice the two that get used are markets - get_markets, get_market, get_market_orderbook, get_market_candlesticks, get_trades - and portfolio - get_balance, get_positions, get_fills, get_orders, create_order, batch_create_orders, batch_cancel_orders, amend_order, decrease_order, order groups, and get_order_queue_position.

Availability

The package installs from PyPI anywhere and needs Python 3.9 or newer. Read-only endpoints work without credentials; anything about your account needs an API key registered on a Kalshi account, which is where the actual gate is.

The flags on this card describe the package, not the exchange. Who may hold a funded Kalshi account is a question about Kalshi and its regulator, and it belongs on kalshi rather than here. A library grants no access it does not already have.

Note the host in Kalshi's own quickstart - api.elections.kalshi.com/trade-api/v2 for production, with a separate demo host. The client does not choose for you.

Pricing

Free to install, with nothing metered and nothing to buy. It is not open source - the wheel's licence expression is LicenseRef-Proprietary, and there is no public repository or licence text to read beyond that string. If your compliance process needs a named OSI licence for every dependency that touches an order path, this package will not pass it.

Kalshi's own trading fees are not this library's. They are on the venue's card.

Markets & resolution

A client resolves nothing. Orders placed through it reach Kalshi's order book and settle in US dollars like any other order there, and the resolution source for each contract is whatever that contract's rules specify - a question for the exchange, not for the SDK. The subject row on this card is blank on purpose - the questions reachable through the client are whatever Kalshi lists, and the library narrows nothing.

The data model the client exposes is worth knowing before you write against it - series contain events, events contain markets, and orders are placed against a market ticker. The generated SeriesApi, EventsApi and MarketsApi map onto those three levels directly.

Integrations

Runtime dependencies are urllib3, python-dateutil, pydantic 2.x, typing-extensions and lazy-imports. Responses come back as pydantic models, which is the one real advantage a generated client has over hand-rolled requests calls - the shapes are typed, and the package ships py.typed.

No CLI, no WebSocket, no MCP server. It is a REST library.

Limitations

No release in over a year. Version 2.1.4 was published on 2025-09-06 and nothing has followed. The entire 2.1.x line shipped across 5-6 September 2025, and the release before it was 2.0.0 from March 2023. For a generated client this is a specific kind of risk - the package is only as current as the last time somebody ran the generator and uploaded the result, and an endpoint Kalshi added since then simply is not in here. You would not learn that from the package; you would learn it from an AttributeError.

You cannot see the source or report a bug against it. Kalshi/exchange-infra is not a public repository, so there is no issue tracker, no commit history and no way to know whether a problem you hit is known. The generated metadata was not even fully filled in - the wheel's Repository URL is the literal OpenAPI Generator placeholder https://github.com/GIT_USER_ID/GIT_REPO_ID, and the __version__ string inside a 2.1.4 wheel still reads 2.1.0. Those are small things, and they tell you how much attention the release got.

An undeclared dependency. Both __init__.py and api_client.py import cryptography at module level to do the RSA-PSS signing, but cryptography is not in the wheel's declared requirements, which list only urllib3, python-dateutil, pydantic, typing-extensions and lazy-imports. In a clean environment that installs nothing else, import kalshi_python itself fails - not some later call - and you add it by hand.

No WebSocket. Kalshi publishes a streaming feed; this client has no path to it. Anything that needs a live book has to be written separately against the raw API.

A second, older repository muddies the name. The 1.x releases came from a personal GitHub repository, lowgrind/kalshi-python, whose README still describes itself as the official Python SDK and whose quickstart authenticates with an email and a password. Its last commit is dated 2022-12-01. That code does not work against today's API, and search results do not distinguish the two.

Alternatives

For a single-venue integration where you want to see and patch the code, a community client is a real option - several exist, and the trade you are making is an unmaintained closed package against a possibly-unmaintained open one, with the difference that you can read the second.

For anything covering more than Kalshi, ccxt implements Kalshi in its prediction namespace with an actively released package, at the cost of speaking CCXT's unified vocabulary rather than Kalshi's. It does not carry Kalshi's WebSocket either.

For reading prices without a client library at all, Kalshi's REST API is plain HTTP and documented - see kalshi-api.