Order Entry Message Types
The Coinbase Derivatives: Predictions Order Entry FIX API supports the following message and execution types. For Logon, heartbeats, sequence recovery, and fill recovery, see Session.Client Message Types
Client Message Types
- NewOrderSingle (35=D): Submits a new limit or market order.
- OrderCancelRequest (35=F): Cancels one open order.
- OrderMassCancelRequest (35=q): Cancels multiple open orders.
System Message and Execution Types
System Message and Execution Types
- ExecutionReport (35=8): Reports order lifecycle events. Execution types are:
- Pending New (150=A): Order accepted and held for the instrument’s speed bump delay.
- New (150=0): Order accepted.
- Trade (150=F): Order partially or fully filled.
- Canceled (150=4): Order canceled by request or by the exchange.
- Expired (150=C): IOC remainder or FOK that could not fill.
- Rejected (150=8): Order rejected by the exchange.
- OrderCancelReject (35=9): Rejection of an
OrderCancelRequest. - OrderMassCancelReport (35=r): Result of an
OrderMassCancelRequest. - MarketSettlementReport (35=UMS): Firm position payout when an instrument settles.
- BusinessMessageReject (35=j): Rejection not reportable with an
ExecutionReport.
Fill Recovery Message Types
Fill Recovery Message Types
Documented on Session, shared with drop copy:
- LastExecIDRequest (35=F1): Client request for the
ExecIDof your newest fill. - LastExecID (35=F2): System response to F1.
- EventResendRequest (35=F3): Client request to replay fills in an
ExecIDrange. - EventResendComplete (35=F4): System response to a successful F3 request.
- EventResendReject (35=F5): System response to an unsuccessful F3 request.
Session Message Types
Session Message Types
Logon (35=A), Logout (35=5), Heartbeat (35=0), TestRequest (35=1), ResendRequest (35=2), Reject (35=3), and SequenceReset (35=4). See Session.
Connection
Connect withTargetCompID (56) = CPMOE and your API key in SenderCompID (49). The API key must have the TRADE permission. Host and port are listed on the Coinbase Derivatives: Predictions Connectivity page. Header fields are on Header/Trailer. Logon, the Logon signature, heartbeats, sequence recovery, and cancel on disconnect are on Session.
SendingTime (52) and TransactTime (60) on messages you receive are UTC timestamps with microsecond precision.
For a read-only copy of your executions, use FIX Drop Copy. For order books and public trades, use FIX Market Data.
Prices, quantities, and sides
Prices, quantities, and amounts are FIX decimal values, not scaled integers.- Inbound values may carry fewer decimal places than the maximum. Extra decimal places are truncated toward zero, not rejected. For example,
44=0.6505is read as0.650. Range checks apply after truncation. Side (54)always refers to the YES contract.1= Buy YES.2= Sell YES. There is no separate NO side on FIX. To buy NO at priceP, sell YES at1.000 - P. To sell NO at priceP, buy YES at1.000 - P.- A YES price of
0.650implies a probability of about 65%. YES price plus NO price equals1.000.
Identifiers
OrderID (37), ExecID (17), TrdMatchID (880), MassActionReportID (1369), and MarketSettlementReportID (20105) are String fields that contain the decimal form of a 64-bit integer.
- Store them as strings or 64-bit integers. They exceed the range of a 32-bit integer.
- Echo
OrderID (37)exactly as received on OrderCancelRequest (35=F). ExecID,MassActionReportID, andMarketSettlementReportIDshare one increasing number space. Compare them numerically to order events. Values are not consecutive.0is a sentinel where no identifier exists, as described on each field.
ClOrdID (11), OrigClOrdID (41), and the sub-account PartyID (448) accept exactly two forms:
- At most 18 printable ASCII characters (
0x20to0x7E). - A 36-character lowercase hyphenated UUID (8-4-4-4-12, IETF variant 2).
ClOrdID also rejects UUIDs of the form 80000000-0000-0000-xxxx-xxxxxxxxxxxx.
NewOrderSingle (35=D)
Submits a new limit or market order. Problems detectable from the request alone are answered immediately with BusinessMessageReject (35=j) and no ExecutionReport follows. All other outcomes are reported with ExecutionReport (35=8).Order type and price rules
A new sub-account string is not itself an error. The sub-account is created on first use.
Executing firm
PartyRole (452) = 1 selects the firm the order is placed for.
- API key scoped to a firm: optional. If sent, it must equal your firm’s ID.
- API key scoped to an FCM: exactly one entry is required, naming an active firm under your FCM.
Text (58) is one of FCM-scoped principal requires exactly one EXECUTING_FIRM, duplicate Parties entry with PartyRole=1 (EXECUTING_FIRM), EXECUTING_FIRM is outside authenticated Firm scope, EXECUTING_FIRM is outside authenticated FCM scope, EXECUTING_FIRM is unknown or inactive, or a PartyID format error.
Max execution cost
MaxExecutionCost (21009) caps the total cost of an FOK order: the cost of the fills plus the taker fee. A buy costs the YES price times quantity. A sell costs 1.000 - price times quantity.
A cap breach is reported as Rejected (
39=8). An FOK that cannot fill its full quantity is reported as Expired (39=C). Handle both terminal statuses for FOK orders, and branch on OrdStatus (39), not Text (58).MaxExecutionCost (21009) is not echoed on execution reports.
Self-match prevention
Self-match prevention stops your orders from trading against each other. There are two independent checks:- Firm level: applies when the aggressing and resting orders have the same firm and the same sub-account, and your firm has a self-match prevention strategy configured. No tags are needed on the order.
- ID based: applies when both orders carry the same positive
SelfMatchPreventionId (7928). The aggressing order’s strategy applies: the8000you sent, otherwise the default configured for your user or firm, otherwiseO.
7928 does not equal the ID registered for your user, the order is rejected with 103=99 and Text (58) = INVALID_FIELD_VALUE. Omit 7928 to opt out of ID-based prevention for an order.
A self-match prevention cancel is reported as Canceled with
378=7 and Text (58) = SELF_MATCH_PREVENTION. On an FOK order, a strategy that would cancel the incoming order makes the order expire with FOK_NOT_FILLED.
OrderCancelRequest (35=F)
Cancels the remaining quantity of one open order. Identify the order byOrderID (37) or OrigClOrdID (41). You can cancel by OrigClOrdID before you receive an ExecutionReport for the order.
A request with neither
37 nor 41 is rejected with BusinessMessageReject, Text (58) = OrderID(37) or OrigClOrdID(41) required.
Each accepted request is answered by exactly one of:
- Canceled ExecutionReport (
150=4). Fills that happened before the cancel took effect are reported first. - OrderCancelReject (35=9).
OrderMassCancelRequest (35=q)
Cancels multiple open orders of your API key. Filters combine with AND.
Each canceled order is reported with a Canceled ExecutionReport,
Text (58) = USER_MASS_CANCEL. Then one OrderMassCancelReport (35=r) summarizes the result. Mass cancel requests are not subject to the session rate throttle.
ExecutionReport (35=8)
Reports order lifecycle events.ExecType (150) identifies the event. Fields common to all execution types:
Pending New (35=8, 150=A)
Sent when an order is accepted on an instrument with a speed bump. The order is not yet matchable. A further report follows when the delay ends.New (35=8, 150=0)
Confirms that an order was accepted.Trade (35=8, 150=F)
Reports a fill. Each fill produces one report per side. Fills trade at the resting order’s price.
Trade reports are the only reports that EventResendRequest (35=F3) can replay.
Canceled (35=8, 150=4)
Confirms that an order was canceled, at your request or by the exchange.- Cancel you requested with OrderCancelRequest:
ClOrdID (11)is the cancel request’sClOrdID, andOrigClOrdID (41)is the order’sClOrdID.378is not sent. - Exchange-initiated cancel (mass cancel, self-match prevention, instrument status change, cancel on disconnect, or exchange operations):
ClOrdID (11)is the order’sClOrdID.41is not sent.
Expired (35=8, 150=C)
Sent in two cases:- IOC remainder: the unfilled quantity of an IOC or market order is removed after matching.
Text (58) = TIME_IN_FORCE. If you cancel such an order yourself, you receive Canceled instead. - FOK that cannot fill: the full quantity is not available, so nothing executes.
Text (58)starts withFOK_NOT_FILLED.
OrdRejReason (103) is never sent on an Expired report.
Rejected (35=8, 150=8)
Reports that the exchange rejected an order after accepting the message.OrdRejReason values
Branch onOrdStatus (39) and OrdRejReason (103). Text (58) labels are more specific but are for logging and diagnosis. New labels can be added, and a label can move to a different 103 value.
OrderCancelReject (35=9)
Sent when an OrderCancelRequest (35=F) cannot be applied. Cancel rejects for requests made through other channels are not sent on FIX.102=1 (Text UNKNOWN_ORDER) covers an order that never existed, an order that is already canceled or expired, and an order that belongs to another user. To tell them apart, check the ExecutionReports you received for that ClOrdID. A fully filled order gets 102=0 with Text ORDER_ALREADY_FILLED.
OrderMassCancelReport (35=r)
Summarizes an OrderMassCancelRequest (35=q). It is sent after the individual Canceled reports.531=7 does not report the scope that ran. Use TotalAffectedOrders (533) to see how many orders were canceled.
MarketSettlementReport (35=UMS)
Sent when an instrument settles, once per firm and instrument. You receive it only if you sentReceiveSettlementReports (20127) = Y on Logon (35=A). Every connected session of the firm that opted in receives the same report.
- With
21053=N, at most one ofLongQtyandShortQtyis non-zero. With21053=G, both can be non-zero. - Settlement is reported per firm, not per sub-account.