New Order Single (35=D)
SenderSubID<50> is captured on an ordinary NewOrderSingle and, per action, on OrderCancelRequest and OrderCancelReplaceRequest; it is ignored on RFQ quote acceptance. The operator on a NewOrderSingle sticks to the order: fills and other lifecycle reports emit it as the PartyRole=12 party. Cancel and Cancel/Replace acknowledgements instead emit the operator sent on that request — the operator who performed the action — falling back to the order’s creating operator when the request carried none. Do not send tag 50 on Logon: Kalshi rejects that Logon.Example New Margin Order
Order Cancel/Replace Request (35=G)
Used to modify an existing order without canceling it.Supported Modifications
- OrderQty: Increase or decrease the quantity. Increasing quantity forfeits queue priority.
- Price: Change the limit price.
-
Expiry: Use Day (
59=0) without126to expire at 11:59:59.999pm ET, set a future deadline withTimeInForce=GTD(59=6) andExpireTime(126), or remove expiry withTimeInForce=GTC(59=1) and no126. Expired deadlines, including the Unix epoch, are rejected.
59 and 126 preserves the
order’s current expiry. This is a Kalshi-specific convention, rather than FIX’s
Day default for omitted 59. To resend expiry explicitly, send 59=6 with the
unchanged 126 for GTD, 59=0 without 126 for Day, or 59=1 without 126
for GTC. Send the current total OrderQty and price for an expiry-only amendment. Kalshi guarantees that an
expiry-only amendment preserves FIFO queue position when price and quantity
are unchanged.
Order Cancel Request (35=F)
Cancel all remaining quantity of an existing order.Execution Report (35=8)
This message is sent by the exchange to reflect changes to an order’s state. Replaced reports confirm the resulting validity withTimeInForce=GTD (59=6)
and the accepted ExpireTime (126), or TimeInForce=GTC (59=1) without 126
when there is no expiry. Kalshi stores Day orders as explicit deadlines, so their
Replaced reports also use GTD with the end-of-day ET deadline; they do not echo
the original Day value.
Order Status (39)
- New<0>: Active order, no fills
- Partially Filled<1>: Some quantity filled
- Filled<2>: Completely filled
- Canceled<4>: Canceled
- Replaced<5>: Order modified via Cancel/Replace
- Pending Cancel<6>: Cancel pending
- Rejected<8>: Order rejected
- Pending New<A>: Order pending acceptance
- Expired<C>: Time-in-force expired
- Pending Replace<E>: Modification pending
With default settings, expiry-style system cancellations are reported as
Canceled<4>. If 21012 (UseExpiredOrdStatus)=Y, expiry-style system cancellations emit Expired<C>.Order Rejection Reasons (103)
- Unknown symbol<1>
- Exchange closed<2>
- Order exceeds limit<3>
- Too late to enter<4>
- Stale order<5>
- Duplicate order<6>
- Unsupported order characteristic<11>
- Incorrect quantity<13>
- Unknown account<15>
- Other<99>
Execution Types (150)
- New<0>
- Trade<F>
- Canceled<4>
- Replaced<5>
- Rejected<8>
- Expired<C>
- Pending New<A>
- Pending Cancel<6>
- Pending Replace<E>
Text Field Values (58)
Common values include:EXCHANGE_UNAVAILABLEINTERNAL_ERRORMARKET_ALREADY_CLOSEDMARKET_INACTIVEMARKET_NOT_FOUNDSELF_CROSS_ATTEMPTORDER_ALREADY_EXISTSEXCEEDED_PER_MARKET_RISK_LIMITEXCEEDED_ORDER_GROUP_RISK_LIMITORDER_GROUP_NOT_FOUNDFOK_INSUFFICIENT_VOLUMEPOST_ONLY_CROSSORDER_GROUP_CANCELTAKER_CANCEL_FOR_SELF_TRADE_PREVENTIONMAKER_CANCEL_FOR_SELF_TRADE_PREVENTIONIMMEDIATE_OR_CANCELLEDREDUCE_ONLY
OrderCancelReject (35=9)
Exchange-returned amend and cancel failures are returned as OrderCancelReject (35=9), not ExecutionReport.Position and Fee Information
WhenExecType = Trade:
Collateral Changes
Party Information
Execution reports independently include the customer account when applicable and at most one operator entry (Executing Trader<12>). Which operator appears depends on the report type: fills and other order-lifecycle reports (expiration, IOC cancellation, and similar) carry the operator captured at order creation, while Cancel and Cancel/Replace acknowledgements carry the operator sent on the acting request, falling back to the creation operator when that request carried none. When both a customer-account entry and an operator entry are present, the customer-account entry comes first.Rejection Reasons (102)
- Too late to cancel<0>
- Unknown order<1>
- Other<99>
Mass Cancel Request (35=q)
Cancel resting orders in bulk. Only available on KalshiNR (NewOrderMode) sessions.530=6 cancels every resting order placed over FIX with the session’s API key. 530=1 cancels every resting order the account has in the market named by Symbol<55>, both sides, however it was placed, or only one subaccount’s when the request names it; it is billed like an order cancel (35=F).
Mass Cancel Report (35=r)
Response to mass cancel request.The report acknowledges the request. Individual ExecutionReports follow for each cancelled order.
Corporate actions: SecurityStatus (35=f)
Every KalshiNR and KalshiRT session, including listener sessions, receives aSecurityStatus (35=f) when the exchange applies a stock split, final settlement or ticker change to any margin market. No request is needed, and cash corporate actions are not sent. Each message follows that market’s earlier execution reports. KalshiRT retains these messages for retransmission like its other messages; KalshiNR sends nothing missed while disconnected, and KalshiMD sessions do not receive them. An applied corporate action can change positions and balances without a fill. Use GET /trade-api/v2/margin/corporate_actions for upcoming and recent notices, including cash actions.
Every event carries CorporateActionNoticeID<20190>, the id of the matching notice in GET /trade-api/v2/margin/corporate_actions. TransactTime<60> is when the exchange applied the action. Money fields are in dollars.
Example applied split
35=c, 35=d, and 35=BP are not used; splits do not change contract terms.