Kalshi’s API gives an institutional desk direct, programmatic access to the exchange: REST and WebSocket for every member, FIX sessions for higher-tier members, key-signed authentication, a request-for-quote system and a full demo environment. What it does not give you is the trading stack around it. Order management, reconciliation, cross-venue risk, execution algorithms and an audit trail remain the desk’s job, and that is the layer Kemet runs on top of the desk’s own Kalshi account and keys.

What the Kalshi API offers

REST and WebSocket

The Trade API v2 is a REST interface covering markets, events, orders, positions, fills, balances and settlements. Kalshi recommends dedicated hosts for API traders, separate from the hosts its own apps use. The WebSocket API streams order book and trade data alongside private channels for your own orders and fills, and Kalshi runs separate lower-latency WebSocket hosts that serve only the fill and order-update channels. Orders and RFQs can be placed under subaccounts, so a desk can separate strategies inside one membership.

FIX for institutional members

Kalshi runs a FIX gateway on FIXT.1.1 with application version FIX 5.0 SP2. Session types include order entry with and without message retransmission, drop copy for historical execution reports, a post-trade stream for settlement reports, a market data session and a dedicated RFQ session for market makers. Members on the Premier tier or above have FIX access by default, and some sessions are gated and requested through Kalshi’s institutional team. Connections require TLS 1.2 or higher, each API key supports one FIX connection, and members at Premier or above can provision AWS PrivateLink so order traffic never crosses the public internet.

Key-based authentication

The API has no username and password login. You generate a key pair, register the public key with Kalshi, and sign every request (a timestamp, the HTTP method and the path) with the private key. Kalshi supports 2048-bit RSA keys, signed with RSA-PSS and SHA-256, and Ed25519 keys, which it now recommends for new integrations. The same key pair works for FIX, where the key ID becomes your SenderCompID. Production and demo keys are separate, and keys can be issued with narrower scopes for read-only uses.

RFQ through the communications endpoints

Kalshi’s request-for-quote system lives under the /communications endpoints. A requester creates an RFQ for a market and a size. Market makers respond privately with a YES bid and a NO bid for the full size, and they cannot see each other’s quotes. The requester accepts one side, the maker confirms within a short window, and the trade executes. RFQs work on any market, including combo markets, over REST, the WebSocket communications channel and FIX, with a cap of 100 open RFQs per user. Block trades are a separate mechanism under Kalshi’s rulebook, covered in our guide to block trading on Kalshi and Polymarket.

Rate limits by tier

Limits are token buckets with separate Read and Write budgets. Most requests cost 10 tokens and your tier sets how fast the bucket refills. At the time of writing, the Basic tier allows 200 read and 100 write tokens per second, roughly 20 reads and 10 order actions a second. Advanced is unlocked with a single API call once at least one of your last 100 orders was placed through the API. Expert, Premier, Paragon, Prime and Prestige are earned from trading volume or arranged with Kalshi. REST and FIX draw from the same buckets, an exhausted budget returns HTTP 429, and the balance endpoint has its own tighter limit, so Kalshi steers integrations toward the fills stream instead of polling.

Demo environment

Kalshi runs a demo exchange with its own REST, WebSocket and FIX hosts and mock funds, though Kalshi notes demo prices and market behaviour may differ from production. Credentials do not carry over, so you register separate demo keys. It is where a desk should test order lifecycle handling, RFQ flows and reconnect logic before a production key exists.

What a desk still has to build

The API is an exchange interface. A desk running capital needs the systems that turn exchange messages into a controlled book.

Order management

Parent orders, child orders, amendments and cancels need state that survives a dropped WebSocket or a FIX reconnect. Kalshi returns order IDs and execution reports. Mapping those back to a trader’s intent, a strategy and an approval is in-house work.

Position and P&L reconciliation

Positions change on fills, settlements and transfers. A desk has to reconcile its own fill log against Kalshi’s positions and settlement reports, and mark open contracts consistently with how it marks everything else it holds.

Risk across venues

Kalshi’s pre-trade checks see your Kalshi account. They do not see the Deribit call spread you bought against a Bitcoin price contract, or the perpetual hedge on another exchange. Cross-venue exposure, limits and margin are the desk’s problem.

Execution algorithms

Event-contract books are often thin outside the headline markets. Working size means slicing over time, hiding quantity, pegging to the touch and stopping when price runs away. Kalshi provides order types. The algorithms are yours to write.

Rate budgets, permissions and audit

Every algo, dashboard and script shares the same token buckets. Someone has to allocate that budget, control which traders can send what, and keep a record of every order, amendment and fill that will stand up to a compliance review.

None of this is exotic. It is the build every desk repeats for each new venue, which is why the build vs buy decision for execution infrastructure deserves a real cost estimate before the first line of code.

How Kemet runs on top of your Kalshi account

Kemet is a technology provider. It is not an exchange, broker, FCM or counterparty, and it never holds client assets. Your desk keeps its own Kalshi membership and API keys, connects them to Kemet, and trades through the platform. Kemet rejects any API key that carries withdrawal rights. Venue access depends on each venue’s own eligibility rules: Polymarket’s international platform, Deribit, Binance and OKX are not available to US persons directly, and US desks reach Polymarket through Polymarket US. Desks should confirm eligibility with counsel.

From there, Kalshi becomes one more venue in a platform covering discovery, execution and position management:

• A trading UI where traders find Kalshi markets, see every outcome of an event in one view, and place orders with price protection and edge limits.
• Execution algorithms on Kalshi contracts, including TWAP, Chase, iceberg and scale strategies, under the same controls the desk uses on options and perpetuals.
• One portfolio and risk view in which Kalshi and Polymarket positions sit next to options, futures, perpetuals and spot on Deribit, Coinbase, OKX, Binance, Bullish, Hyperliquid and Derive.
• The Kemet REST and WebSocket API, so a quant team writes against one interface instead of maintaining a Kalshi client, a Deribit client and a reconciliation job.
• An MCP server that gives AI agents access to market data, positions and order flow inside the permissions the desk sets.
• Order and fill records for every venue in one place, ready for post-trade review.

The cross-venue view is where this pays off. A desk long a Kalshi contract on where Bitcoin settles at month end sees it in the same book as the Deribit options it trades, and can hedge it with an options package sent to RFQ on Deribit, Paradigm or Derive, with auto-hedging that fires on fills against thresholds the desk sets. We cover the mechanics in hedging Kalshi and Polymarket crypto contracts with Deribit options. Desks can also send requests into Kalshi’s own RFQ system from inside Kemet.

Kemet’s Kalshi integration was announced with FalconX and Kalshi in August 2026. In the announcement, FalconX said that FalconX Bravo, Inc. provides liquidity and access to event contracts for institutional counterparties within a CFTC-regulated framework. The details are in the announcement, and our prediction markets overview covers how event contracts fit into an institutional book.

FAQ

Does Kalshi offer a FIX API?

Yes. Kalshi’s FIX gateway runs FIXT.1.1 with FIX 5.0 SP2 and offers order entry, drop copy, post-trade, market data and RFQ sessions. Members on the Premier tier or above have FIX access by default. Some sessions, such as drop copy and post-trade, are gated and requested through Kalshi’s institutional team.

How does Kalshi API authentication work?

You create a key pair, register the public key with Kalshi, and sign each request with the private key over a timestamp, the HTTP method and the request path. Kalshi accepts 2048-bit RSA keys signed with RSA-PSS and SHA-256, and recommends Ed25519 for new keys. The same key pair authenticates FIX sessions.

What are Kalshi’s API rate limits?

Kalshi meters requests with token buckets split into Read and Write budgets, sized by tier from Basic up to Prestige. Most calls cost 10 tokens. Basic allows 200 read and 100 write tokens per second at the time of writing, and higher tiers are earned through trading volume. REST and FIX share the same budgets.

Can I test a Kalshi integration without trading real money?

Yes. Kalshi’s demo environment runs its own REST, WebSocket and FIX hosts with mock funds, though Kalshi notes demo prices and market behaviour may differ from production. Demo keys only work against demo endpoints, so you register them separately.

Does Kemet take custody of funds or trade on my behalf?

No. Your desk keeps its own Kalshi account and keys. Kemet connects to that account, never holds client assets, is never a counterparty, and does not accept API keys with withdrawal rights.

See it on your own account

If your desk is wiring up the Kalshi API and already trades crypto derivatives elsewhere, we can show Kalshi orders, algos and positions running next to your options book. Book a demo.