Drop Copy Session
Overview
The drop copy session provides an alternative method to query for missed execution reports without using the FIX retransmission protocol. This is particularly useful for:- Recovering from connection failures
- Auditing order activity
- Building backup systems
- Compliance recording
Kalshi’s DropCopy format utilizes a request-response message type, if you are interested in a session that “follows along” the execution report activity of your trading
session, consider using a KalshiRT session with the ListenerFlag parameter.
Connection Details
| Environment | URL | Port | TargetCompID |
|---|---|---|---|
| Production | fix.elections.kalshi.com | 8229 | KalshiDC |
| Demo | fix.demo.kalshi.co | 8229 | KalshiDC |
EventResendRequest (35=U1)
Request execution reports within a specified ExecID range.Fields
| Tag | Name | Description | Required |
|---|---|---|---|
| 21001 | BeginExecID | Starting ExecID (inclusive) | Yes |
| 21002 | EndExecID | Ending ExecID (inclusive) | No |
If EndExecID is not provided, it defaults to the latest ExecID in your history.
Limitations
- Lookback Window: Last 3 hours only
- Message Types: Only ExecutionReport (35=8) supported
- Excluded Messages:
- Rejects (no valid ExecID)
- Pending new orders (ExecID = “-1;-1”)
Example Request
EventResendComplete (35=U2)
Sent after all requested events have been resent.Fields
| Tag | Name | Description | Required |
|---|---|---|---|
| 45 | RefSeqNum | MsgSeqNum of the EventResendRequest | Yes |
| 21003 | ResentEventCount | Total number of events resent | Yes |
EventResendReject (35=U3)
Sent when a resend request cannot be fulfilled.Fields
| Tag | Name | Description | Required |
|---|---|---|---|
| 45 | RefSeqNum | MsgSeqNum of the EventResendRequest | Yes |
| 21004 | EventResendRejectReason | Rejection code | Yes |
Rejection Reasons (21004)
| Code | Description |
|---|---|
| 1 | Too many resend requests |
| 2 | Server error |
| 3 | BeginExecID is too small (outside window) |
| 4 | EndExecID is too large |
Usage Patterns
Recovery After Disconnect
1
Track Last ExecID
Store the last processed ExecID before disconnect
2
Reconnect to Drop Copy
Establish new drop copy session
3
Request Missing Events
Send EventResendRequest starting from last ExecID
4
Process Resent Events
Handle execution reports with new sequence numbers
Best Practices
1. ExecID Management
- Store ExecIDs persistently
- Handle the two-part format correctly (e.g., “12345;67890”)
- Implement proper ID comparison logic
2. Rate Limiting
- Avoid excessive resend requests
- Implement exponential backoff on failures
- Batch requests when possible
3. Deduplication
- Events may arrive via both primary and drop copy sessions
- Implement deduplication based on ExecID
- Handle out-of-order delivery
4. Error Recovery
- Handle all rejection codes appropriately
- Implement retry logic with delays
- Alert on persistent failures
Comparison with Retransmission
| Feature | Drop Copy | Retransmission |
|---|---|---|
| Session Type | Separate | Same as order entry |
| Sequence Numbers | Independent | Original preserved |
| Lookback Window | 3 hours | 3 hours |
| Message Types | ExecutionReport only | All types |
| Use Case | Recovery/Audit | Real-time gaps |
All resent messages will have new FIX sequence numbers in the drop copy session, different from their original sequence numbers in the order entry session.