Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.kalshi.com/llms.txt

Use this file to discover all available pages before exploring further.

Kalshi’s FIX implementation uses FIXT.1.1 with application version FIX50SP2. Members on the Premier tier or above have FIX access by default. For all other tiers, contact institutional@kalshi.com to inquire about access.

​
FIX Dictionary

Download the Kalshi-specific FIX dictionary for import into your FIX engine:
If you are using a FIX engine such as QuickFIX/J, QuickFIX/N, or quickfix-go, the standard header and trailer fields below are managed automatically by the library. This section is primarily a reference for custom implementations or debugging.

​
Standard Header

Every FIX message begins with the following fields:
TagNameTypeRequiredDescription
8BeginStringStringYAlways FIXT.1.1
9BodyLengthIntYMessage length in bytes, from the tag after BodyLength up to (but not including) the CheckSum field. Must be the second field.
35MsgTypeStringYIdentifies the message type. Must be the third field.
49SenderCompIDStringYYour FIX API Key (UUID format) when sending; Kalshi when receiving.
56TargetCompIDStringYSession identifier (e.g. KalshiRT, KalshiNR) when sending; your API key when receiving.
34MsgSeqNumIntYMonotonically increasing sequence number, starting at 1.
52SendingTimeUTCTimestampYTime the message was sent, in UTC. Format: YYYYMMDD-HH:MM:SS.mmm. Must be within 30 seconds of server time or the message is rejected (SessionRejectReason=10).
43PossDupFlagBooleanNY if the message is a possible duplicate of a previously sent message (used during retransmission).
97PossResendBooleanNY if the message may contain information that has already been sent under a different sequence number.
122OrigSendingTimeUTCTimestampNOriginal SendingTime of a message being resent. Required when PossDupFlag=Y.

​
Standard Trailer

Every FIX message ends with:
TagNameTypeRequiredDescription
10CheckSumStringYThree-character checksum. Calculated by summing every byte in the message up to (but not including) the CheckSum field, then taking modulo 256. Always three digits, zero-padded (e.g. 007).

​
Supported MsgTypes

​
Session-Level (all sessions)

MsgTypeNameDirection
ALogonBoth
0HeartbeatBoth
1TestRequestBoth
2ResendRequestBoth (KalshiRT/KalshiRFQ only)
3RejectServer -> Client
4SequenceResetBoth (KalshiRT/KalshiRFQ only)
5LogoutBoth

​
Application-Level

​
Order Entry

MsgTypeNameSessionsDirection
DNewOrderSingleKalshiNR, KalshiRTClient -> Server
FOrderCancelRequestKalshiNR, KalshiRTClient -> Server
GOrderCancelReplaceRequestKalshiNR, KalshiRTClient -> Server
qOrderMassCancelRequestKalshiNR, KalshiRTClient -> Server
8ExecutionReportKalshiNR, KalshiRT, KalshiDCServer -> Client
9OrderCancelRejectKalshiNR, KalshiRTServer -> Client
rOrderMassCancelReportKalshiNR, KalshiRTServer -> Client
jBusinessMessageRejectAllServer -> Client

​
Order Groups

MsgTypeNameSessionsDirection
UOGOrderGroupRequestKalshiNR, KalshiRTClient -> Server
UOHOrderGroupResponseKalshiNR, KalshiRTServer -> Client

​
Drop Copy

MsgTypeNameSessionsDirection
ADTradeCaptureReportRequestKalshiDCClient -> Server
AETradeCaptureReportKalshiDCServer -> Client
U1EventResendRequestKalshiDCClient -> Server
U2EventResendCompleteKalshiDCServer -> Client
U3EventResendRejectKalshiDCServer -> Client

​
Post Trade

MsgTypeNameSessionsDirection
UMSMarketSettlementReportKalshiPTServer -> Client

​
RFQ

MsgTypeNameSessionsDirection
RQuoteRequestKalshiRT, KalshiRFQBoth
bQuoteRequestAckKalshiRTServer -> Client
SQuoteKalshiRT, KalshiRFQBoth
AIQuoteStatusReportKalshiRFQServer -> Client
ZQuoteCancelKalshiRFQClient -> Server
U9QuoteCancelStatusKalshiRFQServer -> Client
AGQuoteRequestRejectKalshiRFQServer -> Client
UAAcceptQuoteKalshiRTClient -> Server
UCAcceptQuoteStatusKalshiRTServer -> Client
U7QuoteConfirmKalshiRFQClient -> Server
U8QuoteConfirmStatusKalshiRFQServer -> Client
UERFQCancelKalshiRTClient -> Server
UBRFQCancelStatusKalshiRTServer -> Client