Kalshi FIX API: Access, Specs, and Who Qualifies
The Short Answer
Kalshi runs a FIX gateway alongside its REST and WebSocket APIs, on two hosts: mm.fix.elections.kalshi.com for order entry and marketdata.fix.elections.kalshi.com for market data. Six session types are separated by port and TargetCompID, covering order entry with and without retransmission, drop copy, RFQ and market data. Authentication reuses the same 2048-bit RSA key pair as the REST API, and your API Key ID becomes the SenderCompID. TLS 1.2 or higher is mandatory. Rate limits are not separate: FIX application messages draw on the same token buckets as the equivalent REST operations.
Key Takeaways
- Two hosts, six ports. Order entry and market data are different gateways, not different message types on one connection.
- The RSA key pair is shared with REST, so FIX access does not mean a second credential to manage.
- Sending
SenderSubIDon Logon gets you disconnected. Operator identity goes on each order message instead. - Kalshi does not reset sequence numbers during maintenance. Your side has to, unless you are on the retransmission session.
- FIX buys you session semantics and drop copy, not a private rate limit. The token buckets are shared with REST.
- If you want one integration across venues rather than one protocol per venue, a normalized API answers a different question than FIX does.
What is the Kalshi FIX API?
FIX is the session protocol most institutional trading runs on. Instead of stateless HTTP requests, you hold an authenticated session open, messages carry sequence numbers, and either side can ask for a replay of anything it missed.
Kalshi exposes that alongside the REST and WebSocket surfaces. The appeal is not raw speed in the abstract. It is that a FIX session gives you guaranteed message ordering, gap detection, and a defined recovery path when the connection drops, all of which you would otherwise build yourself on top of a WebSocket.
Which sessions does Kalshi run?
Six, split across two hosts. The port and the TargetCompID together select which one you are connecting to.
| Port | TargetCompID | Purpose |
|---|---|---|
| 8228 | KalshiNR | Order entry, no message persistence or retransmission |
| 8230 | KalshiRT | Order entry with retransmission |
| 8229 | KalshiDC | Drop copy |
| 8231 | KalshiPT | Listener session, read-only execution report stream |
| 8232 | KalshiRFQ | Request for quote |
| 8233 | KalshiMD | Market data |
The distinction between KalshiNR and KalshiRT is worth reading twice, because it decides how your system behaves after an outage. The NR session does not persist messages, so anything sent while you were disconnected is gone. The RT session retains continuity and will replay on request.
How do you authenticate a FIX session?
The credential is the one you already have. Kalshi FIX uses the same RSA key pair as the REST API, so if you are already trading over REST there is no second key to provision.
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out kalshi-fix.key
openssl rsa -in kalshi-fix.key -pubout -out kalshi-fix.pubRegister the public key in your account profile. The API Key ID that comes back, a UUID, is your SenderCompID.
Logon is a standard 35=A with three fields worth calling out:
| Tag | Field | Value |
|---|---|---|
| 98 | EncryptMethod | None<0>, since TLS handles the encryption |
| 96 | RawData | Client logon message signature |
| 108 | HeartbeatInt | Any value greater than 3 |
One trap that costs people an afternoon: do not send SenderSubID (tag 50) on Logon. Kalshi rejects it with a Logout rather than a reject message, which reads like an auth failure and sends you back to checking your key. Operator identity belongs on the individual order messages, on NewOrderSingle, OrderCancelRequest or OrderCancelReplaceRequest.
TLS 1.2 or higher is required and plain TCP is refused. If your FIX engine has no native TLS support, the documented workaround is a local proxy such as stunnel. Default heartbeat interval is 30 seconds, and the connection terminates if a heartbeat response does not arrive inside the interval.
What are the rate limits?
This is where expectations usually need adjusting. FIX does not come with its own budget.
Application messages use the same token model, the same token costs, and the same Read and Write buckets as the equivalent REST operations. Order entry and RFQ messages draw on the Write bucket. If you are moving to FIX expecting the protocol itself to raise your ceiling, it will not.
The details that do differ:
- Session-level messages are free. Logout (
35=5), Heartbeat (35=0) and TestRequest (35=1) are excluded from the limit entirely. - Logon is metered separately from application messages, which matters when you are writing reconnect logic.
- Mass Cancel Request (
35=q) is capped at one per second, independent of everything else. - Sharded markets have their own budget. Order-entry messages carrying
ExDestination(tag 100) with a value of 1 or higher bill to a per-shard Write budget rather than the unscoped one. RFQ quote accepts always bill the unscoped budget.
What happens during maintenance?
Sessions may be disconnected in the maintenance window, and there is one behavior to design around: Kalshi does not initiate sequence number resets. Your client resets on its side when reconnecting.
The exception is KalshiRT, which retains message continuity across the window. If that session drops you can request retransmission of anything missed once you are back.
For resting orders, tag 21006 (CancelOrderOnPause) on your NewOrderSingle decides whether an order survives a trading pause or is pulled. Setting it deliberately is better than discovering the default during an unscheduled pause.
Who actually needs FIX?
Honestly, fewer teams than think they do.
FIX earns its complexity when you need guaranteed sequencing with gap recovery, a drop copy session feeding a separate risk or reconciliation system, or an existing FIX engine you would rather point at a new venue than replace. Those are real requirements and REST does not meet them cleanly.
It earns nothing if what you actually want is lower latency on a handful of orders, or a tidier way to read prices. The REST and WebSocket surfaces cover that, and they cost a fraction of the engineering.
The other consideration is scope. A FIX session is one venue. If your system watches several venues, you are looking at a protocol per venue, each with its own session semantics, its own identifiers and its own recovery behavior.
That is the case for reading through one normalized contract instead. Predictefy serves Kalshi as one of 16 venues on a single schema, so adding a venue is a parameter rather than another protocol to operate:
curl -s "https://data.predictefy.com/api/kalshi/fetchOrderBook?outcomeId=OUTCOME_ID" \
-H "Authorization: Bearer pk_live_YOUR_KEY"Swap kalshi for any served venue and the request shape is unchanged, or use router to ask every venue at once. That answers a different question than FIX does: FIX is about session guarantees on one exchange, while a normalized contract is about one integration across many. Plenty of desks run both, with FIX on the venue they trade hardest and a normalized read layer for everything else.
Frequently Asked Questions
Do you need special approval for Kalshi FIX access?
The credential is the same RSA key pair used for the REST API, registered in your account profile, so there is no separate key provisioning step. Connectivity details including hosts, ports and session types are published openly in Kalshi's FIX documentation rather than gated behind a sales conversation.
Is FIX faster than the Kalshi WebSocket?
FIX gives you session guarantees rather than a promise of lower latency: ordered delivery, gap detection and a defined replay path. If your requirement is recovering cleanly from a dropped connection, that matters more than raw speed. If you simply want live prices, the WebSocket surface is far less engineering.
Why does my FIX logon get a Logout response?
The most common cause is sending SenderSubID on the Logon message, which Kalshi rejects with a Logout rather than a reject. Operator identity belongs on the order messages instead. Check your SenderCompID matches the API Key ID UUID, and that you are connecting over TLS 1.2 or higher.
Does FIX give you a higher rate limit on Kalshi?
No. FIX application messages use the same token model, token costs and Read or Write buckets as the equivalent REST operations. Session messages like Heartbeat and TestRequest are excluded, and Logon is metered separately, but the protocol itself does not raise your ceiling.
What is a drop copy session used for?
Drop copy delivers execution reports to a second consumer, so a risk system or reconciliation process can watch fills without sharing the trading session. Kalshi runs it on port 8229 with TargetCompID KalshiDC, and it also serves for recovering execution reports you missed while disconnected.