Downloads
FIX Specification XML
FIX 5.0 SP2 specification file for the Drop Copy API
The FIX Drop Copy gateway is designed for direct access users: clients placing orders through one of the Starbase order entry gateways. Non-direct users (e.g. orders placed via the Web UI or WebSocket API) are not supported.
Connection and Authentication
FIX Version
The gateway uses FIX 5.0 SP2 (FIXT.1.1). TheBeginString field in the logon message must be set to FIXT.1.1. Connections using an older version (e.g. FIX.4.4) are rejected before parsing can identify the sender, so no reject message is returned.
Logon Fields
- Execution Reports (
35=8) cover orders and trades that occur in the order book. - Trade Capture Reports (
35=AE) cover trades that occur outside the order book.
Mass quotes (submitted via the SBE Mass Quote API) appear in the Drop Copy feed only when they result in fills. Unexecuted quotes are not included.
Open Order Snapshot on Connect
When a new Drop Copy session is established, Starbase immediately sends Execution Reports for all currently open orders. These snapshot messages are sent automatically (no request is needed) and are marked with a snapshot indicator to distinguish them from live messages. This allows clients to synchronize their order state on connect without requesting an ER replay.Report Types
Order book trades: Execution Reports
Execution Reports are sent for all activity that goes through the order book:Reported trades: Trade Capture Reports
Trade Capture Reports are sent for trades that bypass the order book entirely:Drop Copy Message Types
Orders
Orders
- ExecutionReport <8> | 150=0/4/5/A/E: Sent on any new, amended, cancelled, or speed-bumped order.
Trades
Trades
- ExecutionReport <8> | 150=F: Sent on any trade generated by an order.
- TradeCaptureReport <AE>: Sent on any trade not generated by an order (e.g. block trades).
Parties Repeating Group (453)
The new
PartyRole=3 (Client ID) entry carries the name of the ITM (clearing account) that the order actually used. When firm/ITM overrides are enabled on Order Entry, this value reflects the overridden ITM; otherwise it matches the user’s default ITM.Orders
ExecutionReport <8> | 150=0/4/5/A/E
New (150=0), Canceled (150=4), Replaced (150=5), Pending New (150=A), and Pending Replace (150=E) reports share the same subset of Execution Report tags.
- New (
150=0): Confirms a new order in response to any request to generate a new order, such asNewOrderResponse(200)via the SBE Order Entry API. Sent for every new order, even those matched immediately. - Canceled (
150=4): Confirms an order is canceled in response to any request to cancel an order, such asCancelOrderRequest(120)via the SBE Order Entry API or to an unsolicited cancel. - Replaced (
150=5): Confirms order is replaced in response to any request to amend an order such asAmendOrderRequest(110)via the SBE Order Entry API. - Pending New (
150=A): Sent when a new order is speed bumped and queued pending entry to the book. Followed by a New (150=0) report once the speed bump period expires and the order is placed. - Pending Replace (
150=E): Sent when an amended order is speed bumped and queued pending re-entry to the book. Followed by a Replaced (150=5) report once the speed bump period expires and the order is placed.
Trades
ExecutionReport <8> | 150=1 or 150=2
Sent for trades on orders.TradeCaptureReportRequest <AD>
By sending a TradeCaptureReportRequest on a drop copy connection, a replay of non-order book trades (block trades, position moves) is triggered as a series of sequential TradeCaptureReport (35=AE) messages. The replay starts from the ExecID specified in the request. Trades are available for 24 hours. For a full history of all trades, the Websocket APIs should be utilized.
TradeCaptureReport <AE>
Sent for each non-order book trade (block trade, position move), both proactively as trades occur and in response to aTradeCaptureReportRequest.
Fill Execution Report Replay
The Drop Copy connection supports on-demand replay of fill Execution Reports (150=1 or 150=2) using two message types. Non-fill Execution Reports (150=0/4/5/A/E) are not replayed; use the open order snapshot to recover order state after a reconnect. Fill reports are retained for 24 hours.
ExecIDs are sequential integers assigned per member and track fill events only. The typical flow is to first request the current last fill ExecID as a baseline, then request a replay starting from that point.
LastFillExecIDRequest <F1>
Sent by the client to retrieve the server’s current last fillExecID for this member.
Response: LastFillExecID <F2>
EventResendRequest <F3>
Requests replay of fill Execution Reports (150=1 or 150=2) within an ExecID range. The server streams all matching reports in order, then sends EventResendComplete. Only fill events within the 24-hour retention window are available.
Replayed fill Execution Reports are identical in format to live fill reports. There is no flag or field distinguishing a replayed message from a live one.
Reject: EventResendReject <F5>
BEGIN_EXEC_ID_TOO_SMALL means BeginExecId is older than the 24-hour retention window, or no fill Execution Reports exist yet for this member. Send a LastFillExecIDRequest to re-establish a valid baseline.END_EXEC_ID_TOO_LARGE means EndExecId refers to an event that does not yet exist. Omit EndExecId to replay up to the current last fill event.