Kalshi API: choose public data, streams or account access

By PredictionToolkit · Published 2026-11-03

You do not need the same access for a market browser and an order engine. Define the data and actions first, then choose Kalshi's native API or a wrapper with the right credentials, environment and operating model.

Choose the event-contract API

Kalshi's documentation separates Predictions APIs for event contracts from Perps APIs for perpetual futures. For prediction-market work, begin with Predictions. The public REST quickstart retrieves series, events, markets and order books without authentication; it does not establish anonymous access to account data or order placement.

Match credentials to the interface

• Public market REST reads: use the documented public endpoints for discovery and book snapshots.
• WebSocket: authenticate the connection handshake even when subscribing to public market-data channels; those channels do not add a second channel-level authorization check.
• Account and trading operations: use the required signed requests and the account's permitted capabilities.

The current key guide supports Ed25519 and RSA-PSS. Choose a key type your actual client version supports instead of copying an older RSA-only example. A key ID identifies the registered key; the private key signs requests. Keep that private key out of browser bundles, public repositories and logs, and use the official signing guide for the exact method and path.

Keep demo and production separate

The recommended REST hosts are external-api.kalshi.com for production and external-api.demo.kalshi.co for demo, with /trade-api/v2 as the API base path. Demo and production keys are not interchangeable. Start account-dependent development in demo and explicitly check the environment before enabling a production action. A demo result does not validate live liquidity or execution.

Direct client, local wrapper or hosted service?

Direct integration keeps Kalshi's own identifiers and API contracts visible. PMXT offers a shared SDK interface where a venue implements the capability. In self-hosted mode, local pmxt-core connects to the venue and uses venue-native credentials when needed. Hosted PMXT uses its own key and infrastructure; documented hosted writes use PreFundedEscrow custody. Compare method support and custody for the chosen mode, not only the SDK's function names.

Build one bounded data flow first

• Resolve the series, event and market ticker and retain the exact contract rules. An event name is not an executable market identifier.
• Read a small market/book sample and retain timestamps, price units and available size before building a chart or comparison.
• For streams, handle connection loss and state recovery; an open connection alone does not prove current usable data.
• Check the account's current limits and endpoint costs, and back off on HTTP 429 responses.
• Review account permissions and order semantics separately from a successful public-data request.

Budget capacity and money separately

Kalshi documents token-based request budgets, including separate read and write budgets. Tokens here meter API capacity; a requests-per-second number from an old example is not a universal allowance. Check current endpoint costs and tier rules. A hosted vendor's plan, your infrastructure and exchange trading charges are separate cost categories.

The sources below were reviewed for this guide's access decisions. No key was created, account connected or order submitted. Use the linked profiles to compare integration surfaces, and the official references to confirm the exact endpoint and permissions before implementation.