FIX API
message which represents
Workflow
After connecting and logging on, the client can either request a security list or subscribe to market data.
Custom fields
Tag | Name | Type |
---|---|---|
20101 | QReqID | String |
20102 | Amount | Qty |
20103 | Address | String |
20104 | PaymentID | String |
20105 | TransactionCompleted | Boolean |
20106 | TransactionID | String |
20107 | VenueTransactionID | String |
20108 | TransactionFee | Qty |
20109 | TransactionsListType | Int |
Security list
Optional: Server offers a security list that supplies the definitive list of symbols traded on the exchange.
- Client sends a
Security List Request <x>
- Server responds with a
Security List <y>
Market data subscription
After connecting to the the market data channel, the client subscribes to market data by sending a Market Data Request <V>
message.
When a client disconnects for any reason, the market data subscription is terminated. Upon reconnecting, the client needs to send another Market Data Request <V>
message.
- Client sends a
Market Data Request <V>
- Server responds by sending one Market Data -
Snapshot/Full Refresh <W>
- As bids, offers, trades and/or actions happen on the exchange, Server sends Market Data -
Incremental Refresh <X>
messages
Logon < A> message
The Logon <A>
message must be the first message sent by the application requesting to initiate a FIX session. The Logon <A>
message authenticates an institution establishing a connection to Server.
Tag | Name | Req | Description |
---|---|---|---|
98 | EncryptMethod | Y | Server does not support encryption. Valid values: 0 = None. |
108 | HeartBtInt | Y | Heartbeat <0> message interval (seconds). |
141 | ResetSeqNumFlag | N | Indicates that the both sides of the FIX session should reset sequence numbers. Valid values: Y = Yes, reset sequence numbers N = No. |
Logout < 5> message
The Logout <5>
message initiates or confirms the termination of a FIX session. Disconnection without the exchange of Logout <5>
messages should be interpreted as an abnormal condition.
Workflow After connecting, logging on, and synchronizing sequence numbers, the client can submit orders. All identifiers must be unique like GUID or UUID.
New Order Single < D> message
To submit a new order to server, send a New Order Single <D>
message. Server will respond to a New Order Single <D>
message with an Execution Report <8>
.
For lib Quickfix C#
NewOrderSingle newOrderSingle = new NewOrderSingle(
new ClOrdId("00000000-0000-0000-0000-000000000001"),
new Symbol("BTC/USD"),
new Side(Side.BUY),
new TransactTime(DateTime.Now),
new OrdType(OrdType.LIMIT))
{
OrderQty = new OrderQty(0.1m),
Price = new Price(1m),
Account = account,
AcctIDSource = new AcctIDSource(AcctIDSource.OTHER)
};
testFixApp.Send(newOrderSingle);
Tag | Name | Req | Description |
---|---|---|---|
11 | ClOrdID | Y | Unique identifier of the order as assigned by the client. Must be unique like GUID or UUID. |
1 | Account | N | Market account id |
660 | AcctIDSource | Y * (required if use Account <1> ) |
Type of account. Should be 99 = Other (custom or proprietary) This field is required if 1 = Account contains account identifier. |
40 | OrdType | Y | Order type. Valid values: 1 = Market 2 = Limit |
44 | Price | Y * (required if OrdType <40> = 2 Limit) |
Price per unit of quantity |
38 | OrderQty | Y | Quantity ordered. Needed > 0 |
54 | Side | Y | Side of the order. Valid values: 1 = Buy 2 = Sell |
55 | Symbol | Y | Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC |
59 | TimeInForce | N | Specifies how long the order remains in effect. Valid values: 1 = Good Till Cancel (GTC) 3 = Immediate or Cancel (IOC) 4 = Fill or Kill (FOK) |
60 | TransactTime | Y | Time of request creation |
Submitting an order
- Client sends server →
New Order Single <D>
message - Does server accept the order?
- Yes, order is accepted for initial processing
- server sends client ← an
Execution Report <8>
for a new order with:ExecType <150>
set to I = Order StatusOrdStatus <39>
set to A = Pending New
- Is the order marketable?
- Yes, server executes one or more initial fills
- server sends client ← an
Execution Report <8>
for each fill or partial fill - Does the order have remaining quantity?.
- Yes, server puts the remaining quantity on the book
- No, server closes the order
- No, server puts the entire quantity of the order on the book
- No, order is rejected
- server sends client ← an
Execution Report <8>
indicating the order was rejected with:ExecType <150>
set to 8 = RejectedOrdStatus <39>
set to 8 = Rejected
Execution Report < 8> message
Server uses the Execution Report <8>
message to:
*confirm the receipt of an order
*confirm the successful cancellation of an order
*relay fill information on orders
*reject orders
Tag | Name | Req | Description |
---|---|---|---|
37 | OrderID | Y | Unique identifier of the order as assigned by the server. Possible "NONE" and ExecType <150> = 8 Rejected when order not found |
11 | ClOrdID | Y * (Required for existing order) | Current unique identifier of the order as assigned by the client. |
41 | OrigClOrdID | N * (Required if client change ClOrdID in Order Cancel/Replace Request <G> message or Order Cancel Request <F> message) |
Previous unique identifier of the order as assigned by the client if current ClOrdID it was changed |
17 | ExecID | Y | Unique identifier of execution message as assigned by server. |
150 | ExecType | Y | Describes the purpose of the Execution Report Possible values: I = Order Status 6 = Pending Cancel E = Pending Replace F = Trade 8 = Rejected |
39 | OrdStatus | Y | Describes the current order status Possible values: A = Pending New 0 = New 1 = Partially filled 2 = Filled 4 = Canceled 8 = Rejected |
58 | Text | N | Error description if contains |
54 | Side | Y | Side of the order. Possible values: 1 = Buy 2 = Sell B = "As Defined" (when ExecType <150> = 8 Rejected and/or order not found) |
55 | Symbol | Y | Ticker symbol. |
14 | CumQty | Y | Total quantity of the order that is filled. Zero (0) when ExecType <150> = 8 Rejected and order not found |
151 | LeavesQty | Y | Quantity open for further execution. Zero (0) when ExecType <150> = 8 Rejected and order not found |
31 | LastPx | Y * (Required if ExecType <150> = F Trade) |
Price of this fill |
32 | LastQty | Y * (Required if ExecType <150> = F Trade) |
Quantity of this fill |
6 | AvgPx | Y | Calculated average price of all fills on this order |
790 | OrdStatusReqID | Y * (Required if responding to and if provided on the Order Status Request <H> message. Echo back the value provided by the requester.) |
Uniquely identify a specific Order Status Request <H> message. |
584 | MassStatusReqID | Y * (Required if responding to a Order Mass Status Request <AF> . Echo back the value provided by the requester.) |
Uniquely identify a specific Order Mass Status Request <AF> message. |
911 | TotNumReports | Y * (Required if responding to a Order Mass Status Request <AF> . Echo back the value provided by the requester.) |
Total number of reports returned in response to a request |
912 | LastRptRequested | Y * (Required if responding to a Order Mass Status Request <AF> . Echo back the value provided by the requester.) |
Indicates whether this message is that last report message in response to a Order Mass Status Request <AF> .Y = Last message N = Not last message |
Order Cancel/Replace Request < G> message
The order cancel/replace request is used to change the parameters of an existing order. Do not use this message to cancel the remaining quantity of an outstanding order, use the Order Cancel Request <F>
message for this purpose.
For lib Quickfix C#
OrderCancelReplaceRequest orderCancelReplaceRequest = new OrderCancelReplaceRequest(
new OrigClOrdID(clOrdId.ToString()),
clOrdId = new ClOrdID(Guid.NewGuid().ToString()),
new Symbol("BTC/USD"),
new Side(Side.BUY),
new TransactTime(DateTime.Now),
new OrdType(OrdType.LIMIT))
{
Price = new Price(2m),
OrderQty = new OrderQty(0.2m)
};
testFixApp.Send(orderCancelReplaceRequest);
Tag | Name | Req | Description |
---|---|---|---|
11 | ClOrdID | Y | New unique identifier of the existing order as assigned by the client. (new if needed, otherwise it can be equal OrigClOrdID) |
41 | OrigClOrdID | Y | Current unique identifier of the order as assigned by the client. |
40 | OrdType | Y | Order type. Valid values: 2 = Limit Must be equal of an existing order |
44 | Price | Y | Price per unit of quantity New value of Price and/or OrderQty |
38 | OrderQty | Y | Quantity ordered. Needed > 0 New value of Price and/or OrderQty |
54 | Side | Y | Side of the order. Valid values: 1 = Buy 2 = Sell Must be equal of an existing order |
55 | Symbol | Y | Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC Must be equal of an existing order |
59 | TimeInForce | N | Specifies how long the order remains in effect. Valid values: 1 = Good Till Cancel (GTC) 3 = Immediate or Cancel (IOC) 4 = Fill or Kill (FOK) Must be equal of an existing order |
60 | TransactTime | Y | Time of request creation |
Submitting an order changes
- Client sends server →
Order Cancel/Replace Request <G>
message - Does server accept the changes?
- Yes, changes is accepted for initial processing
- server sends client ← an
Execution Report <8>
for a change order with:ExecType <150>
set to E = Pending Replace- Current status of order
- Is the order marketable?
- Yes, server executes one or more initial fills
- server sends client ← an
Execution Report <8>
for each fill or partial fill - Does the order have remaining quantity?
- server sends client ← an
- No, server puts the entire quantity of the order on the book
- Yes, server executes one or more initial fills
- server sends client ← an
- No, changes is rejected
- server sends client ← an
Order Cancel Reject <9>
message indicating the changes was rejected with:CxlRejResponseTo <434>
set to 2 =Order Cancel/Replace Request <G>
OrdStatus <39>
set to current order status. IfCxlRejReason <102>
= 'Unknown Order', specify 8 = Rejected.- If order not found,
CxlRejReason <102>
set to 1 = Unknown order.
- server sends client ← an
- Yes, changes is accepted for initial processing
Order Cancel Request < F> message
The Order Cancel Request <F>
message requests the cancellation of all of the remaining quantity of an existing order.
For lib Quickfix C#
OrderCancelRequest orderCancelRequest = new OrderCancelRequest(
new OrigClOrdID(clOrdId.ToString()),
new ClOrdID(Guid.NewGuid().ToString()),
new Symbol("BTC/USD"),
new Side(Side.BUY),
new TransactTime(DateTime.Now)
)
{ OrderQty = new OrderQty(0.1m) };
testFixApp.Send(orderCancelRequest);
Tag | Name | Req | Description |
---|---|---|---|
11 | ClOrdID | Y | New unique identifier of the existing order as assigned by the client. (new if needed, otherwise it can be equal OrigClOrdID) |
41 | OrigClOrdID | Y | Current unique identifier of the order as assigned by the client. |
38 | OrderQty | Y | Quantity ordered. Needed > 0, but there is nothing to do. Will be try cancellation of all of the remaining quantity. |
54 | Side | Y | Side of the order. Valid values: 1 = Buy 2 = Sell Must be equal of an existing order |
55 | Symbol | Y | Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC Must be equal of an existing order |
60 | TransactTime | Y | Time of request creation |
Submitting an order cancel
- Client sends server →
Order Cancel Request <F>
message - Does server accept cancel order request?
- Yes, request is accepted for initial processing
- server sends client ← an
Execution Report <8>
for a cancellation order with:ExecType <150>
set to 6 = Pending Cancel- Current status of order
- Successful cancellation of an order? server sends client ← an
Execution Report <8>
for order with:ExecType <150>
set to 4 = Canceled- Current status of order
- server sends client ← an
- No, request is rejected
- server sends client ← an
Order Cancel Reject <9>
message indicating the cancellation was rejected with:CxlRejResponseTo <434>
set to 1 =Order Cancel Request <F>
OrdStatus <39>
set to current order status. IfCxlRejReason <102>
= 'Unknown Order', specify 8 = Rejected.- If order not found,
CxlRejReason <102>
set to 1 = Unknown order.
- server sends client ← an
- Yes, request is accepted for initial processing
Order Status Request < H> message
The Order Status Request <H>
message is used by the client to generate an order status message (Execution Report <8>
message) back from the server.
For lib Quickfix C#
OrderStatusRequest orderStatusRequest = new OrderStatusRequest(
clOrdId,
new Symbol("BTC/USD"),
new Side(Side.BUY),
);
testFixApp.Send(orderStatusRequest);
Tag | Name | Req | Description |
---|---|---|---|
11 | ClOrdID | Y | New unique identifier of the existing order as assigned by the client. (new if needed, otherwise it can be equal OrigClOrdID) |
790 | OrdStatusReqID | N | Can be used to uniquely identify a specific Order Status Request <H> and response message. |
Response on Order Status Request <H>
is an Execution Report <8>
message with current order status. ExecType <150>
in a response may have two values: 8 = Rejected (if order not found) and I = Order Status. Execution Report <8>
response contain OrdStatusReqID <790>
if request contain it.
Order Mass Status Request < AF> message
The Order Mass Status Request <AF>
message requests the status for orders matching criteria specified within the request.
For lib Quickfix C#
OrderMassStatusRequest orderMassStatusRequest = new OrderMassStatusRequest(
new MassStatusReqID(Guid.NewGuid().ToString()),
new MassStatusReqType(MassStatusReqType.STATUS_FOR_ALL_ORDERS))
{
Side = side,
Symbol = symbol
};
testFixApp.Send(orderMassStatusRequest);
Tag | Name | Req | Description |
---|---|---|---|
584 | MassStatusReqID | Y | Value assigned by issuer of Mass Status Request to uniquely identify the request and responses. |
585 | MassStatusReqType | Y | Mass Status Request Type Valid values: 1 = Status for orders for a security 7 = Status for all orders |
1 | Account | N | Filtering orders by market account id. |
660 | AcctIDSource | Y * (required if use Account <1> ) |
Type of account. Valid value: 99 = Other (custom or proprietary) |
54 | Side | Y | Side of the order. Valid values: 1 = Buy 2 = Sell |
55 | Symbol | Y | Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC |
Responses on Order Mass Status Request <AF>
message is an Execution Reports <8>
messages with current order status. ExecType <150>
in a response may have two values: 8 = Rejected (if matching criteria is incorrect) and I = Order Status.
If ExecType <150>
is 8 = Rejected, then
OrderID <37>
= "-" and OrdStatus <39>
= 8 (Rejected)
If Symbol <55>
not set in request then Symbol <55>
in response = "-"
If Side <54>
not set in request then Side <54>
in response = B ("As Defined")
Execution Reports <8>
contains MassStatusReqID <584>
, TotNumReports <911>
and LastRptRequested <912>
.
Security List Request < x> message
The Security List Request <x>
message is used to return a list of securities from the server that match criteria provided on the request.
For lib Quickfix C#
SecurityListRequest securityListRequest = new SecurityListRequest(
new SecurityReqID(Guid.NewGuid().ToString()),
new SecurityListRequestType(SecurityListRequestType.SYMBOL)
)
{
Symbol = new Symbol("BTC/USD")
};
testFixApp.Send(securityListRequest);
Tag | Name | Req | Description |
---|---|---|---|
320 | SecurityReqID | Y | Unique ID of a Security Definition Request |
559 | SecurityListRequestType | Y | Identifies the type/criteria of Security List Request Valid values: 0 = Symbol <55> 4 = All Securities |
55 | Symbol | Y * (required if use SecurityListRequestType <559> = 0 (Symbol <55> )) |
Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC |
207 | SecurityExchange | N | Filtering security by market name. Like “Kraken" |
15 | Currency | N | Filtering security by settlement currency. Like “BTC” for “ETH/BTC” |
Response on Security List Request <x>
message is Security List <y>
message.
Security List < y> message
The Security List <y>
message is used to return a list of securities that matches the criteria specified in a Security List Request <x>
.
Tag | Name | Req | Description |
---|---|---|---|
320 | SecurityReqID | Y | Unique ID of a Security Definition Request |
322 | SecurityResponseID | Y | Unique ID of a Security (if SecurityRequestResult <560> = 0 (Valid request)) |
560 | SecurityRequestResult | Y | The results returned to a Security Request message. Possible values: 0 = Valid request 1 = Invalid or unsupported request 2 = No instruments found that match selection criteria |
146 | NoRelatedSym | Y | Specifies the number of repeating symbols specified. |
=>55 | Symbol | Y * (required if SecurityRequestResult <560> = 0 (Valid request)) |
Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC |
=>207 | SecurityExchange | Y * (required if SecurityRequestResult <560> = 0 (Valid request)) |
Market name. |
=>15 | Currency | Y * (required if SecurityRequestResult <560> = 0 (Valid request)) |
Identifies currency used for price. |
=>561 | RoundLot | Y * (required if SecurityRequestResult <560> = 0 (Valid request)) |
The trading lot size of a security |
=>562 | MinTradeVol | N * (if SecurityRequestResult <560> = 0 (Valid request) and the market provides this value, then it is) |
The minimum trading volume for a security |
393 | TotNoRelatedSym | Y | Total number of securities returned in response to a request |
893 | LastFragment | Y | Indicates whether this message is that last report message in response to a Security List Request <x> .Y = Last message N = Not last message |
Market Data Request < V> message
Subscribes the current session to a Market Data - Snapshot/Full Refresh <W>
followed by zero or more Market Data - Incremental Refresh <X>
messages.
For lib Quickfix C#
MarketDataRequest marketDataRequest = new MarketDataRequest(
new MDReqID(Guid.NewGuid().ToString()),
new SubscriptionRequestType(SubscriptionRequestType.SNAPSHOT),
new MarketDepth(5))
{
MDUpdateType = new MDUpdateType(MDUpdateType.FULL_REFRESH),
};
var bid = new MarketDataRequest.NoMDEntryTypesGroup()
{
MDEntryType = new MDEntryType(MDEntryType.BID)
};
var ask = new MarketDataRequest.NoMDEntryTypesGroup()
{
MDEntryType = new MDEntryType(MDEntryType.OFFER)
};
var symGroup = new MarketDataRequest.NoRelatedSymGroup
{
Symbol = new Symbol("BTC/USD")
};
marketDataRequest.AddGroup(bid);
marketDataRequest.AddGroup(ask);
marketDataRequest.AddGroup(symGroup);
testFixApp.Send(marketDataRequest);
Tag | Name | Req | Description |
---|---|---|---|
262 | MDReqID | Y | Unique identifier for Market Data Request <V> |
263 | SubscriptionRequestType | Y | Subscription Request Type Valid values: 0 = Snapshot 1 = Snapshot + Updates (Subscribe) 2 = Disable previous Snapshot + Update Request (Unsubscribe) |
264 | MarketDepth | Y | Depth of market for Book Valid values: 0 = Full Book 1 = Top of Book N> = Report best N price tiers of data |
265 | MDUpdateType | Y * (required if SubscriptionRequestType <263> = 1 ( Snapshot + Updates (Subscribe))) |
Specifies the type of Market Data update. Valid values: 0 = Full Refresh 1 = Incremental Refresh |
267 | NoMDEntryTypes | Y | Number of MDEntryType <269> fields requested. |
=>269 | MDEntryType | Y * (required if NoMDEntryTypes <267> > 0) |
Type Market Data entry. Valid values: 0 = Bid 1 = Offer 2 = Trade |
146 | NoRelatedSym | Y | Specifies the number of repeating symbols specified. |
=>55 | Symbol | Y * (required if NoRelatedSym <146> > 0) |
Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC |
=>207 | SecurityExchange | N | Name of the exchange. e.g. “Kraken” Subscribed to all exchanges if not specified. |
If a subscription error occurs, server will return Market Data Request Reject <Y>
message with MDReqID <262>
refer to the MDReqID <262>
of the request.
MDReqRejReason <281>
(Reason for the rejection of a Market Data request) in Market Data Request Reject <Y>
message may be not set or:
Possible values:
0 = Unknown symbol
1 = Duplicate MDReqID <262>
4 = Unsupported SubscriptionRequestType <263>
5 = Unsupported MarketDepth <264>
6 = Unsupported MDUpdateType <265>
8 = Unsupported MDEntryType <269>
There may be an error description in the field Text <58>
.
Market Data - Snapshot/Full Refresh < W> message
The Market Data messages are used as the response to a Market Data Request <V>
message
Tag | Name | Req | Description |
---|---|---|---|
262 | MDReqID | Y | Unique identifier for Market Data Request <V> |
55 | Symbol | Y | Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC |
207 | SecurityExchange | Y | Market name. |
268 | NoMDEntries | Y | Number of entries in Market Data message. |
=>269 | MDEntryType | Y * (required if NoMDEntries <268> > 0) |
Type Market Data entry. Possible values: 0 = Bid 1 = Offer 2 = Trade |
=>270 | MDEntryPx | Y * (required if NoMDEntries <268> > 0) |
Price <44> of the Market Data Entry. |
=>271 | MDEntrySize | Y * (required if NoMDEntries <268> > 0) |
Quantity <53> or volume represented by the Market Data Entry. |
Market Data - Incremental Refresh < X> message
The Market Data messages are used as the response to a Market Data Request <V>
message after Market Data - Snapshot/Full Refresh <W>
message when SubscriptionRequestType <263>
= 1 ( Snapshot + Updates (Subscribe)) and MDUpdateType <265>
= 1 (Incremental Refresh)
Tag | Name | Req | Description |
---|---|---|---|
262 | MDReqID | Y | Unique identifier for Market Data Request <V> |
268 | NoMDEntries | Y | Number of entries in Market Data message. |
=>269 | MDEntryType | Y * (required if NoMDEntries <268> > 0) |
Type Market Data entry. Possible values: 0 = Bid 1 = Offer 2 = Trade |
=>270 | MDEntryPx | Y * (required if NoMDEntries <268> > 0) |
Price <44> of the Market Data Entry. |
=>271 | MDEntrySize | Y * (required if NoMDEntries <268> > 0) |
Quantity <53> or volume represented by the Market Data Entry. |
=>279 | MDUpdateAction | Y * (required if NoMDEntries <268> > 0) |
Type of Market Data update action. Possible values: 0 = New 1 = Change 2 = Delete |
=>55 | Symbol | Y * (required if NoMDEntries <268> > 0) |
Ticker symbol. Common, "human understood" representation of the security. e.g. ETH/BTC |
=>207 | SecurityExchange | Y * (required if NoMDEntries <268> > 0) |
Market name. |
Balances Request < bQ> message (custom message)
Subscribes the current session to a Balance Data.
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier for Balances Request <bQ> |
263 | SubscriptionRequestType | Y | Subscription Request Type Valid values: 0 = Snapshot 1 = Snapshot + Updates (Subscribe) 2 = Disable previous Snapshot + Update Request (Unsubscribe) |
1 | Account | N | Account identifier. If not specified all active balances from all accounts will send. |
15 | Currency | N | Currency name. If not specified all active balances from currencies will send.Can contain multiple currencies separated by a comma, like “BTC,USD,EUR” |
Balances Refresh < bU> message (custom message)
The Balances Refresh messages are used as the response to a Balances Request <bQ>
message.
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier of Balances Request <bQ> |
20102 | Amount | Y | Amount of currency on exchange. |
1 | Account | Y | Account identifier. |
15 | Currency | Y | Currency name. |
Balances Reject < bF> message (custom message)
If a subscription error occurs, server will return Balances Reject <bF>
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier of Balances Request <bQ> |
58 | Text | N | Message to explain reason for rejection. |
Deposit Address Request < wQ> message (custom message)
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier for Deposit Address Request <wQ> |
1 | Account | Y | Account identifier. |
15 | Currency | Y | Currency name. |
Deposit Address < wA> message (custom message)
The Deposit Address messages are used as the response to a Deposit Address Request <wQ>
message.
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier for Deposit Address Request <wQ> |
20103 | Address | Y | Address of cryptocurrency wallet. |
20104 | PaymentID | N | Payment identifier if applicable for cryptocurrency. |
Withdraw Request < wW> message (custom message)
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier of Withdraw Request <wW> |
20102 | Amount | Y | Amount of currency to withdraw. |
1 | Account | Y | Account identifier. |
15 | Currency | Y | Currency name. |
20103 | Address | Y | Address of cryptocurrency wallet. |
20104 | PaymentID | N | Payment identifier if applicable for cryptocurrency. |
Withdraw Ack < wR> message (custom message)
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier of Withdraw Request <wW> |
Transactions List Request < wLD> message (custom message)
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier for Transactions List Request <wLD> |
1 | Account | Y | Account identifier. |
15 | Currency | Y | Currency name. |
20109 | TransactionsListType | Y | Type of transactions list. Valid values: 1 = Withdraw 2 = Deposit |
916 | StartDate | N | Begin date and time of transaction in the list. Format: 01/26/2018 14:27:45 |
917 | EndDate | N | End date and time of transaction in the list. Format: 01/26/2018 14:27:45 |
Transactions List < wld> message (custom message)
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier for Transactions List Request <wLD> |
20109 | TransactionsListType | Y | Type of transactions list. Valid values: 1 = Withdraw 2 = Deposit |
893 | LastFragment | Y | Indicates if this message in a fragmented response |
20103 | Address | Y | Address of cryptocurrency wallet. |
20104 | PaymentID | N | Payment identifier if applicable for cryptocurrency. |
20102 | Amount | Y | Amount of currency. |
20105 | TransactionCompleted | Y | Does transaction completed or not. |
20106 | TransactionID | Y | Transaction identifier in the blockchain. |
20107 | VenueTransactionID | N | Internal identifier of the transaction provided by exchange. |
20108 | TransactionFee | N | Fee of transaction in native blockchain currency. |
504 | PaymentDate | Y | Date when transaction issued. |
58 | Text | N | Transaction description, if provided by exchange. |
Withdraw Reject < wF> message (custom message)
Possible reject message for Deposit Address Request <wQ>
, Withdraw Request <wW>
and Transactions List Request <wLD>
.
Tag | Name | Req | Description |
---|---|---|---|
20101 | QReqID | Y | Unique identifier of rejected request. |
58 | Text | N | Where possible, message to explain reason for rejection. |
Reject < 3> message
Description
The Reject <3>
message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. MsgType <35>
=&) which successfully passes de-encryption, CheckSum <10>
and BodyLength <9>
checks. As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.
Rejected messages should be logged and the incoming sequence number incremented.
Note: The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request <2>
will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop, which may be encountered in this situation.
Generation and receipt of a Reject <3>
message indicates a serious error that may be the result of faulty logic in either the sending or receiving application.
If the sending application chooses to retransmit the rejected message, it should be assigned a new sequence number and sent with PossResend <97>
=Y.
Whenever possible, it is strongly recommended that the cause of the failure be described in the Text <58>
field (e.g. INVALID DATA - FIELD 35).
If an application-level message received fulfills session-level rules, it should then be processed at a business message-level. If this processing detects a rule violation, a business-level reject should be issued. Many business-level messages have specific "reject" messages, which should be used. All others can be rejected at a business-level via the Business Message Reject <j>
message. See Volume 1: "Business Message Reject <j>
" message.
Note that in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system, a Business Message Reject <j>
with BusinessRejectReason <380>
= "Application not available at this time" should be issued.
Scenarios for session-level Reject <3>
:
SessionRejectReason <373>
0 Invalid tag number
1 Required tag missing
2 Tag not defined for this message type
3 Undefined Tag
4 Tag specified without a value
5 Value is incorrect (out of range) for this tag
6 Incorrect data format for value
7 Decryption problem
8 Signature <89>
problem
9 CompID problem
10 SendingTime <52>
accuracy problem
11 Invalid MsgType <35>
12 XML Validation error
13 Tag appears more than once
14 Tag specified out of required order
15 Repeating group fields out of order
16 Incorrect NumInGroup count for repeating group
17 Non "data" value includes field delimiter (SOH character)
99 Other
(Note other session-level rule violations may exist in which case SessionRejectReason <373>
of Other may be used and further information may be in Text <58>
field.)
RESTFul API Public Endpoints
message which represents
General
Requests parameters for POST requests (authenticated) in the "Authenticated Enpoints" section are part of the PAYLOAD, not GET parameters.
Requests parameters for GET requests (non-authenticated) are appended as sub-path of request URL.
For example:
https://<client host:port>/v1/ticker/<symbol>/<exchange>
URL depends on customer’s dedicated service.
/v1
– protocol version
/ticker
– method name
/<symbol>
- name of exchange currency pair (ETH_BTC, BTC_USD …)
/<exchange>
- name of exchange (Bitfinex, HitBTC …)
< symbol> or trading pair name implies that the base currency is written first then the settlement currency using underscore separator. It means when buy order of ETH_BTC executed, trader obtained ETH and paid by BTC. Or – when sell order of ETH_BTC executed, trader paid for ETH to obtain BTC.
Quants framework provides access to multiple exchanges using single API interface.
< exchange> could be the following:
Exchange | Public trades | Withdrawal API | Comments |
---|---|---|---|
Bitfinex | Y | Y | |
Kraken | Y | Y | |
Bittrex | Y | Y | |
HitBTC | Y | Y | |
Liqui | Y | N | |
Cryptopia | N | Y | Only single buy or sell order at time |
Poloniex | Y | Y |