Kalshi API Guide: Public Data & Rate Limits (2026)

Start a Kalshi API project by reading public market data. Add authenticated account requests only when you need them, then test execution separately in the demo environment. An API client retrieves data or submits instructions; it does not establish a profitable strategy.

Read public markets without a key

The official market-data quick start documents unauthenticated access. This Python example fetches one page of open markets; it does not place orders.

import requests

base = "https://external-api.kalshi.com/trade-api/v2"
response = requests.get(
    f"{base}/markets",
    params={"status": "open", "limit": 5},
    timeout=15,
)
response.raise_for_status()
for market in response.json().get("markets", []):
    print(market["ticker"], market["title"])

Install the dependency with python -m pip install requests. An empty list is a valid response. A collector spanning more than one page must follow pagination. Save retrieval timestamps and preserve market rules alongside quotes; a market title alone is insufficient for comparing contracts.

Kalshi API keys and signed authentication

For dedicated setup and signing-path troubleshooting, use the API-key guide and signing-message builder.

Create a key under Account & security → API Keys. Keep its ID and private PEM file secure. Authenticated requests use KALSHI-ACCESS-KEY, KALSHI-ACCESS-TIMESTAMP and KALSHI-ACCESS-SIGNATURE. Sign the millisecond timestamp, HTTP method and full URL path, excluding query parameters. RSA keys use RSA-PSS/SHA-256; Ed25519 keys sign directly. Follow the official signed-request example for your key type and environment.

For a balance request, the full signing path is /trade-api/v2/portfolio/balance. Keep production and demo credentials separate. Never paste a private key into a research prompt, screenshot, committed file or public support message.

Kalshi rate limits: tokens, not one fixed request speed

Kalshi's current rate-limit documentation describes independent Read and Write token buckets. Basic Predictions budgets refill at 200 and 100 tokens per second respectively. Most requests cost 10 tokens, giving 20 reads or 10 writes per second at that cost. Endpoint costs vary: inspect GET /account/endpoint_costs and your account's GET /account/limits.

A 429 response calls for exponential backoff. The docs currently say these responses omit Retry-After headers. Batch items consume tokens individually; batching does not remove their cost. Burst capacity and shard routing affect writes. Perps has separate limits, so use the relevant documentation for your product.

Design the collector before the trading bot

1. Retrieve a narrow set of markets and validate their rules.
2. Record prices, available size and retrieval time.
3. Handle empty results, pagination, timeouts and throttling explicitly.
4. Print proposed decisions and compare them with later outcomes.
5. Before execution, test account recovery, position reconciliation, cancellation and maximum exposure in demo.

These are implementation checks, not evidence of investment returns. A filled order can lose its entire purchase cost. A stale quote or small apparent spread is insufficient grounds for automated execution.

Fees and realistic fills

Use the venue's current fee estimate and Kalshi fees guide when evaluating a trade. API access does not make trading fee-free. Check depth in the order-book guide, then compare execution assumptions with the slippage calculator. Its examples are illustrative rather than live quotes.

Where to go next

The Python guide covers a focused language workflow. The GitHub guide helps evaluate SDKs and community repositories. Use Polymarket API documentation guidance when building a separate venue adapter. Alphascope's market research can support investigation; verify contract rules and executable prices at the venue before acting.

Documentation checked October 6, 2026. Account configuration and the current official API reference take precedence over this guide.