Kalshi API: What KYC and Fees Mean for Access

The most important fact about the Kalshi API is not technical, it is legal. Kalshi operates as a CFTC-regulated designated contract market, which means every account behind an API key belongs to a verified, KYC-approved person, and every trade clears against a fee schedule Kalshi publishes in advance. That separates it from permissionless prediction markets where anyone can query and trade from an anonymous wallet.

The Kalshi API is a trading and market-data interface for a regulated US event-contract exchange. You authenticate against a real, identity-verified account, read live and historical market data over REST and WebSocket endpoints documented at docs.kalshi.com, and place or cancel orders that settle in US dollars under exchange rules.

Key takeaways

• The Kalshi API requires a verified account. There is no anonymous read-and-trade path, because Kalshi is a CFTC-regulated exchange subject to KYC obligations.
• Authentication uses API keys tied to your account, with request signing, per the official Kalshi API docs.
• Kalshi publishes a fee schedule, so your trading cost is known before you place an order rather than inferred from onchain gas.
• The API surface splits into public market data, private portfolio and order data, and a WebSocket feed for real-time updates.
• Rate limits are tiered, and higher throughput generally requires an upgraded access tier documented by Kalshi.

Why the regulated framing changes how you build

If you have integrated a crypto prediction market before, the muscle memory does not transfer cleanly. On a permissionless market, price and depth are onchain state you can read from any node, and a bot can trade with nothing but a funded wallet. Kalshi works differently. It is an exchange first, so the API mirrors what a broker-dealer or futures venue exposes rather than what a smart contract exposes.

That matters right now because event contracts have moved from a legal grey zone into an actively litigated, actively regulated space. Kalshi has fought and won court battles over its right to list certain contracts, and the CFTC's posture toward these markets keeps shifting. If you want the background on how Kalshi sits inside US law, we cover it in the legal analysis of whether Kalshi counts as gambling and its standing in California. For API builders, the practical consequence is that your integration inherits compliance surface. Accounts can be restricted by jurisdiction, contracts can be delisted, and identity verification is not optional.

How access works, step by step

1. Create and verify an account. Kalshi runs KYC on real users. An API key is issued against that verified account, not against an address you generate yourself.
2. Generate API credentials. Kalshi's developer documentation describes creating an API key and using it to sign authenticated requests. The public market-data endpoints can be read without full trading authentication, but any portfolio or order action requires signed, account-bound calls.
3. Read market data. Query markets, events, and series to discover what is tradable, then pull order books, trades, and candlestick history for the contracts you care about.
4. Subscribe to the WebSocket feed. For live order-book and ticker updates, Kalshi exposes a WebSocket channel rather than making you poll REST in a tight loop.
5. Place and manage orders. Authenticated endpoints let you submit, amend, and cancel orders and read your fills and positions.
6. Respect rate limits. Requests are throttled per tier. Design for backoff and, where you need scale, request an appropriate access tier as described in Kalshi's docs.

For the mechanics of how an order becomes a settled payout on Kalshi, our walkthrough of Kalshi from order to payout traces the full lifecycle.

What each API surface returns

The endpoints group into three practical categories. Field names and exact routes should be read from the Kalshi API reference, which is the authoritative source and changes over time.

Pricing is denominated in cents, and the fee is knowable in advance

Kalshi contracts trade between 1 and 99 cents, where the price is the market's implied probability of the event resolving Yes. A contract at 40 cents pays out 1 dollar if it resolves Yes, so you risk 40 cents to make 60. Because Kalshi is an exchange, it charges a trading fee that is published rather than paid as variable network gas. Kalshi's fee schedule defines the formula, which scales with price and quantity.

Here is why the published schedule matters in practice. On a permissionless onchain market, your true cost per trade includes gas that fluctuates with network congestion, so identical trades can cost different amounts minutes apart. On Kalshi, the fee is a deterministic function of contract price and size. The cost curve is not flat: fees are structured so they peak for contracts trading near the middle of the range, where uncertainty and volume concentrate, and taper toward the 1-cent and 99-cent extremes. The exact numbers live in Kalshi's published schedule, so verify against that document before you size a strategy.

Kalshi API versus a permissionless prediction market API

The deeper distinction shows up when you try to read history. On an onchain market, the ledger is the record, and anyone can reconstruct every trade from public blocks. Kalshi's matching engine is private infrastructure, so the API is the record, and what you can reconstruct is bounded by what the endpoints return and how far back they reach. If you are building models on Kalshi history, our guide to working with Kalshi historical data covers the retention and granularity constraints.

Concrete before-and-after for a builder

• Predictable cost: capital math is stable because the fee comes from a published formula, not from gas that spikes during a congested block. You can compute worst-case cost before submitting.
• Fewer settlement surprises: positions clear in US dollars under exchange rules, so you are not tracking stablecoin bridges or waiting on chain finality to know a payout landed.
• Compliance is priced in: because access requires a verified account, you can operate a US-facing product without engineering your own identity layer, at the cost of losing anonymous access.

Comparing Kalshi with onchain markets means normalizing two different records

Suppose you want one dataset that puts a Kalshi contract next to the equivalent onchain prediction market, so you can compare where prices diverge on the same real-world event. Those two records do not share a schema. Kalshi returns exchange fields (market ticker, price in cents, contract quantity, account-scoped fills) from its API. A permissionless market returns onchain fields (wallet address, token amount, transaction hash, block timestamp) from public blocks. To ask a single question across both, the same trade has to resolve to the same fields: event, outcome, price as probability, size, and timestamp on a common clock.

That normalization is the problem Allium works on. Allium ingests and standardizes prediction-market data, with dedicated Kalshi tables alongside its broader prediction-market datasets, so a Kalshi contract and an onchain market resolve into comparable rows you can query together. Allium is the data infrastructure for onchain finance, built for cross-source reconciliation. The wider deep-dive on how to access this category lives in our guide to accessing prediction market data.

Risks and open questions

• Regulatory drift. Which contracts Kalshi may list, and in which states, is unsettled and litigated. Contracts you depend on can be delisted, and access can change by jurisdiction.
• Docs are the moving target. Endpoint routes, auth flows, and rate limits change. Treat docs.kalshi.com as the single source of truth and pin nothing from a third-party summary, including this page.
• History has boundaries. Because the matching engine is private, historical depth and granularity are whatever Kalshi exposes, not the full public record you would get from a blockchain.
• Rate limits constrain scale. A naive polling loop will hit throttles fast. Real-time strategies need the WebSocket feed and careful backoff.

Frequently asked questions

Do I need a verified account to use the Kalshi API?

Yes for trading and portfolio access. Kalshi is a CFTC-regulated exchange, so any authenticated endpoint (orders, fills, balances) requires an identity-verified account and an account-bound API key. Public market-data endpoints can be read without full trading authentication, per Kalshi's documentation at docs.kalshi.com.

Is the Kalshi API free?

Reading public market data does not carry a per-call charge in the way a paid data vendor might, but trading is not free. Kalshi charges a published trading fee defined in its fee schedule, and higher API throughput may require an upgraded access tier. Always confirm current terms in Kalshi's own docs.

How is the Kalshi API different from a permissionless prediction market API?

Kalshi's API is an exchange interface with KYC accounts, request-signed keys, published fees, and US-dollar settlement. A permissionless onchain market is read directly from public blockchain state, trades from any wallet, and settles in crypto. The Kalshi API is the source of truth for its data because the matching engine is private.

Does Kalshi offer real-time data over WebSocket?

Yes. Kalshi exposes a WebSocket feed for real-time order-book, ticker, and fill updates, which is the intended path for low-latency use instead of polling REST endpoints in a tight loop. See docs.kalshi.com for channel details.

How far back does Kalshi historical data go?

Historical depth and granularity are whatever Kalshi's API exposes, since the exchange matching engine is private rather than an open ledger. If you need standardized, queryable history for research or backtesting, Allium maintains dedicated Kalshi tables built for that use.

Can I compare Kalshi prices with onchain prediction markets programmatically?

Only after normalization. Kalshi returns exchange fields (ticker, price in cents, contract quantity) while onchain markets return blockchain fields (wallet, token amount, transaction hash). To query both together, each trade must resolve to shared fields like event, outcome, probability, size, and a common timestamp, which is the reconciliation problem Allium's prediction-market datasets address.