Kalshi SDK (2026): Which One to Install and Why

Which Kalshi SDK should you install?

Pick by language, and in Python by whether your code is async. All three packages are generated from Kalshi's OpenAPI specification and released together, generally on a Tuesday or Wednesday each week, ahead of the API changes they cover.

pip install kalshi_python_sync     # blocking calls, the simplest place to start
pip install kalshi_python_async    # asyncio, for services that run many requests at once
npm install kalshi-typescript      # Node.js and TypeScript, built on axios

Here is the field you will run into when you search a package registry:

What happened to kalshi-python?

It was the original Python SDK, and it is still the one most older tutorials import. Kalshi's SDK page now marks it deprecated and points to the sync and async packages instead. Its last release, 2.1.4, dates from September 2025, while the current packages track the API every week.

If an example you are copying imports kalshi_python, translate it to kalshi_python_sync rather than installing the old package. The client class and configuration pattern carry over; the method set is what has moved on.

Why does pip install an old version of the Kalshi SDK?

Because the current Python packages require Python 3.13 or newer, and pip does not stop to tell you. On Python 3.12, pip install kalshi_python_sync succeeds, but what it installs is 3.2.0, the newest release that still supports 3.12, rather than 3.30.0. Code copied from today's documentation can then call methods that version does not have.

python --version                           # needs 3.13 or newer
pip install "kalshi_python_sync==3.30.0"   # pinning makes an old interpreter fail loudly
pip show kalshi_python_sync                # confirm the version you actually got

How do you authenticate with the Kalshi Python SDK?

Every Kalshi SDK signs requests with an API key ID and an RSA private key, using RSA-PSS. Create the key in your Kalshi account, following how to get a Kalshi API key, keep the private key file out of your repository, and hand both to the client:

from kalshi_python_sync import Configuration, KalshiClient

config = Configuration(host="https://external-api.kalshi.com/trade-api/v2")
config.api_key_id = "YOUR_API_KEY_ID"
with open("kalshi-private-key.pem") as f:
    config.private_key_pem = f.read()

client = KalshiClient(config)

markets = client.get_markets(limit=5, status="open")
first = markets.markets[0]
book = client.get_market_orderbook(ticker=first.ticker)
balance = client.get_balance()

Market status accepts unopened, open, paused, closed and settled. For rate limits and the tier system behind them, see Kalshi API rate limits.

What does the Kalshi TypeScript SDK look like?

The TypeScript client is generated with positional arguments and returns axios responses, which makes it more verbose than the Python client but just as complete:

import { readFileSync } from 'node:fs';
import { Configuration, MarketApi, PortfolioApi } from 'kalshi-typescript';

const config = new Configuration({
  apiKey: process.env.KALSHI_API_KEY_ID,
  privateKeyPem: readFileSync('kalshi-private-key.pem', 'utf8'),
  basePath: 'https://external-api.kalshi.com/trade-api/v2',
});

const markets = new MarketApi(config);
const { data } = await markets.getMarkets(5);
const book = await markets.getMarketOrderbook(data.markets[0].ticker);

const portfolio = new PortfolioApi(config);
const balance = await portfolio.getBalance();

Can the Kalshi SDK place orders?

Yes. Order methods use V2 names that reflect Kalshi's newer order endpoints, which is why a quick search for create_order comes up empty.

Creating an order posts to /portfolio/events/orders. The same client also covers order groups, request for quote and your portfolio's fills, positions and settlements. If a partially filled order is confusing you, reading the Kalshi order book first usually explains why.

How do you test against the Kalshi demo exchange?

Change the host and the key, nothing else. Kalshi runs a separate demo exchange with mock funds at https://external-api.demo.kalshi.co/trade-api/v2, with WebSockets at wss://external-api-ws.demo.kalshi.co/trade-api/ws/v2. Demo and production credentials are separate, so create an API key inside your demo account.

Kalshi notes that demo prices and behaviour may not reflect real markets, which makes the demo ideal for testing authentication and order flow, and less useful for judging a strategy. The difference, and how to paper trade against Kalshi's real order books instead, is covered in Kalshi paper trading.

When should you skip the Kalshi SDK?

Kalshi's own guidance is that production traders should treat the OpenAPI and AsyncAPI specifications as the source of truth, and consider generating their own client or integrating directly for full control. Two situations push most teams that way: an endpoint the SDK has not caught up with yet, and a strategy that needs more than one venue.

The second case is where one multi-venue client pays off. Predictefy's SDK reads Kalshi and Polymarket, together with 15+ prediction market venues, through the same methods:

import { Predictefy } from '@predictefy/sdk';

const client = new Predictefy({ apiKey: process.env.PREDICTEFY_API_KEY });

const kalshi = await client.kalshi.fetchMarkets({ query: 'fed', status: 'active', limit: 5 });
const polymarket = await client.polymarket.fetchMarkets({ query: 'fed', status: 'active', limit: 5 });

For a side-by-side of the two venues' raw APIs, see Kalshi API vs Polymarket API, and for the case for one integration across every venue, is there one API for all prediction markets.

Frequently Asked Questions