Introduction

Welcome to the Crypto.com Exchange FIX API - FIX API reference documentation.

Change Logs

• 2025-07-09 - Update 35=D, tag18=8 SMART_POST_ONLY
• 2025-06-26 - Aded 35=G for OrderCancelReplaceRequest
• 2025-05-29 - Update 35=V, tag MarketDepth(264) include market depth 1.
• 2025-04-23 - Update FIX housekeeping period date
• 2025-02-06 - Added tag 10060 into tag 35=8
• 2024-10-25 - Added tag 20101 and tag 20102 into tag 35=8
• 2024-09-26 - Added tag 880 TrdMatchID into tag 35=8
• 2024-09-10 - FIX 3.0 initial
• 2024-06-28 - Added Self Trade Prevention (STP) feature
• 2023-10-03 - Added tag544=2 for margin trading in 35=D
• 2023-06-04 - Added OTC RFS Flow
• 2023-04-25 - Added 35=W or market data
• 2023-04-17 - Update 35=D, update tag1107 remove '=I' , '=M'
• 2023-04-17 - Updated details on 35=X, NoMDEntries(268)
• 2023-02-23 - Add wait interval in 35=A
• 2023-02-06 - Added tag 278 include details with order books
• 2023-02-02 - MDS 2.0 initial
• 2023-02-01 - Added tag18 in execution report
• 2022-12-02 - Update on tag 35=2
• 2022-12-01 - Update description on tag 20001
• 2022-11-22 - Update the default COMPIDs
• 2022-11-18 - Included the response and reason codes
• 2022-11-14 - Update tag 1107 TriggerPriceType description
• 2022-10-18 - Updated cancellation request tag 35=F
• 2022-09-08 - Updated logon requests
• 2022-06-30 - Updated mass order request
• 2022-03-21 - Initial v3 API

Generating the API Key

Before sending any requests, you'll need to generate a new API key.

This can be done in the Exchange website under User Center - API.

After generating the key, there are two things you need to carefully note down:

• API Key
• Secret Key

API Key and Secret are randomly generated by the system and can not be modified. Default settings will be set to "Can Read" only, and you have the option of adding or removing certain permissions for your API Key via Web UI.

You can optionally specify a whitelist of IP addresses when generating the API Key.

If specified, the API can only be used from the whitelisted IP addresses.

Rate Limits

FIX

FIX API Overview

What is FIX API

FIX (Financial Information eXchange) is a standard electronic messaging protocol which can be used to place orders, receive order updates and executions, and cancel orders. Our FIX API is based on the FIX 4.4 specification and modeled after FIX implementations of other popular cryptocurrency exchanges.

Users who are less familiar with FIX can also consider using the REST API or Web Socket API.

FIX Dictionary

Our FIX API implementation is based on the FIX Protocol 4.4 specifications, and on top of it we also includes some tags from other versions of the FIX Specification, as well as some User Defined Fields.

We provide a custom dictionary in the QuickFIX XML format, which is also compatible with various FIX engine implementations.

Download FIX Dictionary for Order Management / Market data

FIX Endpoints

The FIX API is available across 3 servers: the user data server (order management), user data server (drop copy), and the market data server.

UAT Sandbox

FIX API (Spot/Deriv)

Production

FIX API (Spot/Deriv)

Remarks for market data flow:

BTC related pair
port: 34402
note: ETH/BTC is NOT included on this instance

ETH related pair
port: 34403
note: ETH/BTC is included on this instance

Others [start with character]
port: 34405 [0-9A-D]
port: 34406 [E-M]
port; 34407 [N-Z]

FIX Connectivity

• To establish a FIX session, FIX clients must setup/use the AWS private link connection.

FIX Session Management

Starting a Session

FIX API runs the server side of the FIX connection ("acceptor"). Sequence numbers start at 1 and must be incremented with every message. Messages with duplicate or out-of-order sequence numbers will be rejected. We never reset sequence numbers on the server side during the logon workflow.

Standard Session Recovery

Standard ResendRequest can be used to recover a session.

1. Send 35=2 with the need sequence number range.
2. Receive replay message with PossDupFlag=Y. Apply the changes based on standard FIX protocol. If a message with this sequence number has been previously received, ignore message, if not, process normally.
3. Continue trading.

Ending a Session

The client may send the server an optional Logout (35=5) message, but the exchange will not interpret its absence as being an abnormal condition.

Under certain conditions, the server may send the client a Logout (35=5) message where the Text (58) field contains the reason.

FIX Messages

This documentation uses | to represent the FIX field separator (byte 0x01). It should be replaced by 0x01 in actual messages.

Standard Header

The header identifies the message type, length, destination, sequence number, origination point and time

Two fields help with resending messages.
The PossDupFlag 43=Y when resending a message as the result of a session level event (i.e. the retransmission of a message reusing a sequence number).
The PossResend 97=Y when reissuing a message with a new sequence number (e.g. resending an order).

The receiving application should process these messages as follows:

• PossDupFlag (43=Y) — if a message with this sequence number has been previously received, ignore message, if not, process normally.
• PossResend (97=Y) — forward message to application and determine if previously received (i.e. verify order id and parameters).

Standard Trailer

Each FIX message is terminated by a Standard Trailer as a message delimiter as well as containing the checksum value.

Logon (35=A)

FIX Digital Signature

For FIX API, the Logon (35=A) message has to be invoked ONCE per session, with the Digital Signature as Password (554) and API key as UserName (553) to be part of the message. Once authenticated, you will gain access to a FIX session, and no longer need to use the pass in the Digital Signature and API key anymore for the duration of the session.

The authentication is based on the pairing of the API Key, along with the HMAC-SHA256 hash of the request parameters using the API Secret as the cryptographic key.

The algorithm for generating the HMAC-SHA256 signature is as follows:

1. (Case i. Order Management Flow) Concatenate the following: "public/auth" + MsgSeqNum (34) + api_key + "system_labelONEEX" + RawData (96)
   (Case ii. Market Data Flow) Concatenate the following: "public/auth" + MsgSeqNum (34) + api_key + RawData (96)
   (Case iii. Drop Copy Flow) Concatenate the following: "public/auth" + MsgSeqNum (34) + api_key + "system_labelONEEX" + RawData (96)
2. Use HMAC-SHA256 to hash the above using the API Secret as the cryptographic key
3. Encode the output as a hex string -- this is your Digital Signature

The above method is similar to sign a Digital Signature for REST / WS, with the following equivalent field mappings:

Please refer to the repsective section to sign a Digital Signature for REST / WS for sample code.

Remarks

We recommend adding 50 ms wait interval after receiving 35=A on both side, before sending first request.

The FIX gateway maintainance (Order Management flow only) will be carried out on second Thursday 07:05-07:15 (UTC) monthly.
Please disconnect on 07:04 (UTC) and reconnect on 07:15 (UTC) with sequence number 1/1.

Other options for client preferences:

option 1:
Sequence number resets require by clients to LOGOFF and then LOGIN again using the Logon [A] message with the ResetSeqNumFlag (141) set to 'Y'. This resets the sequence numbers on both sides. Clients are free to perform this action whenever is convenient for their own schedule and set-up.

Option 2:
Crypto.com FIX connections shall establish a cap to prevent sequence number counter overflow; Our FIX engine shall trigger disconnection and reset the sequence number to 1/1, either the inbound or outbound sequence number reach 2,147,480,000

Logout (35=5)

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.

Before actually closing the session, the logout initiator should wait for the opposite side to respond with a confirming Logout<5> message. This gives the remote end a chance to perform any Gap Fill operations that may be necessary. The session may be terminated if the remote side does not respond in an appropriate timeframe.

After sending the Logout<5> message, the logout initiator should not send any messages unless requested to do so by the logout acceptor via a ResendRequest<2>.

Heartbeat (35=0)

The Heartbeat (0) monitors the status of the communication link and identifies when the last of a string of messages was not received.

• When either end of a FIX connection has not sent any data for [ HeartBtInt (108) ] seconds, it will transmit a Heartbeat (0) message.
• When either end of the connection has not received any data for ( HeartBtInt (108) + "some reasonable transmission time") seconds, it will transmit a Test Request (1) message.
• If there is still no Heartbeat (0) message received after ( HeartBtInt (108) + "some reasonable transmission time") seconds then the connection should be considered lost and corrective action be initiated.
• If HeartBtInt (108) is set to zero then no regular heartbeat messages will be generated. Note that a test request message can still be sent independent of the value of the HeartBtInt (108) , which will force a Heartbeat (0) message.
• Heartbeats issued as the result of Test Request (1) must contain the TestReqID (112) transmitted in the Test Request (1) message. This is useful to verify that the Heartbeat (0) is the result of the Test Request (1) and not as the result of a regular timeout.

TestRequest (35=1)

The Test Request (1) message forces a heartbeat from the opposing application. The Test Request (1) message checks sequence numbers or verifies communication line status. The opposite application responds to the Test Request (1) with a Heartbeat (0) containing the TestReqID (112).

The TestReqID (112) verifies that the opposite application is generating the heartbeat as the result of Test Request (1) and not a normal timeout. The opposite application includes the TestReqID (112) in the resulting Heartbeat (0). Any string can be used as the TestReqID (112) (one suggestion is to use a timestamp string).

ResendRequest (35=2)

The resend request is sent by the receiving application to initiate the retransmission of messages. This function is utilized if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialization process.

The resend request can be used to request a single message, a range of messages or all messages subsequent to a particular message.

Note: the sending application may wish to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has elapsed since its original inception, the sender may not wish to retransmit the order given the potential for changed market conditions. (The Sequence Reset-GapFill <4> message is used to skip messages that a sender does not wish to resend.)

Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.

• To request a single message: BeginSeqNo (7) = EndSeqNo (16)
• To request a range of messages: BeginSeqNo (7) = first message of range, EndSeqNo <16> = last message of range
• To request all messages subsequent to a particular message: BeginSeqNo (7) = first message of range, EndSeqNo (16) = 0 (represents infinity) .

Tag	Name	Type	Required	Description
7	BeginSeqNo	number	Y	First sequence number in the range to be resent. Please refer [FIX Sequence Number Resent scenario] for more details
16	EndSeqNo	number	Y	Last sequence number in the range to be resent. For single message resend requests, set BeginSeqNo = EndSeqNo. If request is for all messages subsequent to a particular message, EndSeqNo = 0.
[FIX Sequence Number Resent scenario] (Assume client is the initiator, CDC is the acceptor. The following is the synchronization after successful logon)
------------------------------Case 1 :------------------------------ After logon request 35=A, CDC found that there are missing sequence number and requires retransmission of messages from client. ResendRequest(35=2) sent by CDC.
------------------------------Case 2:------------------------------ After logon request 35=A, client found that there are missing sequence number and requires retransmission of messages from CDC. ResendRequest(35=2) sent by client.
------------------------------Case 3:------------------------------ ResendRequest(35=2) sent by client and CDC after Logon(35=A) acknowledgement.

SequenceReset (35=4)

The Sequence Reset message has two modes: Gap Fill mode and Reset mode.

Gap Fill mode

Gap Fill mode is used in response to a Resend Request <2> when one or more messages must be skipped over for the following reasons:

• During normal resend processing, the sending application may choose not to send a message (e.g. an aged order).
• During normal resend processing, a number of administrative messages are skipped and not resent (such as Heart Beats, Test Requests).

Gap Fill mode is indicated by GapFillFlag <123> field = "Y".

If the GapFillFlag <123> field is present (and equal to "Y"), the MsgSeqNum <34> should conform to standard message sequencing rules (i.e. the MsgSeqNum <34> of the Sequence Reset <4> GapFill mode message should represent the beginning MsgSeqNum <34> in the GapFill range because the remote side is expecting that next message sequence number).

Reset mode

Reset mode involves specifying an arbitrarily higher new sequence number to be expected by the receiver of the Sequence Reset <4>-Reset mode message, and is used to reestablish a FIX session after an unrecoverable application failure.

Reset mode is indicated by the GapFillFlag <123> field = "N" or if the field is omitted.

If the GapFillFlag <123> field is not present (or set to N), it can be assumed that the purpose of the Sequence Reset <4> message is to recover from an out-of-sequence condition. In Sequence Reset <4> - Reset mode, the MsgSeqNum <34> in the header should be ignored (i.e. the receipt of a Sequence Reset <4> - Reset mode message with an out of sequence MsgSeqNum <34> should not generate resend requests). Sequence Reset <4> - Reset should NOT be used as a normal response to a Resend Request <2> (use Sequence Reset <4> - Gap Fill mode). The Sequence Reset <4> - Reset should ONLY be used to recover from a disaster situation which cannot be recovered via the use of Sequence Reset <4> - Gap Fill. Note that the use of Sequence Reset <4> - Reset may result in the possibility of lost messages.

Rules for processing all Sequence Reset messages:

• The sending application will initiate the Sequence Reset <4>. The message in all situations specifies NewSeqNo <36> to reset to as the value of the next sequence number to be expected by the message receipient immediately following the messages and/or sequence numbers being skipped.
• The Sequence Reset <4> can only increase the sequence number.
• If a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error.
• One must be careful to ignore the duplicate Sequence Reset <4>-GapFill mode which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum <34> is less than expected. If so, the Sequence Reset <4>-GapFill mode is a duplicate and should be discarded.

NewOrderSingle (35=D)

Creates a new BUY or SELL order on the Exchange.

This call is asynchronous, so the response with Pending New is simply an acceptance of the request, but not necessarily mean it is confirmed into order book.

The drop copy subscription can be used to check when the order is successfully created.

See FIX Spot Order Life Cycle and ExecutionReport for details.

Here are the mandatory parameters based on OrdType:

Helpful information:

• STOP_LIMIT and TAKE_PROFIT_LIMIT will execute a LIMIT order when the TriggerPrice is reached.
• STOP_LOSS and TAKE_PROFIT will execute a MARKET order when the TriggerPrice is reached.

To create trigger orders against market price:

• TriggerPrice below market price: BUY STOP_LOSS and STOP_LIMIT, SELL TAKE_PROFIT and TAKE_PROFIT_LIMIT
• TriggerPrice above market price: SELL STOP_LOSS and STOP_LIMIT, BUY TAKE_PROFIT and TAKE_PROFIT_LIMIT

Response Attributes

See FIX Spot Order Life Cycle and ExecutionReport for details.

OrderCancelReplaceRequest (35=G)

Cancel/Replace will be used to change any valid attribute of an open order (i.e. reduce/increase quantity, change limit price, change instructions, etc.),

Requests which cannot be processed will be rejected using the Cancel Reject <9> message. The Cancel Reject <9> message should provide the ClOrdID <11> and OrigClOrdID <41> values which were specified on the Cancel/Replace Request message for identification.

Response Attributes

See FIX Spot Order Life Cycle and ExecutionReport for details.

OrderCancelRequest (35=F)

Cancels an existing order on the Exchange (asynchronous)

This call is asynchronous, so the response as ExecutionReport with Pending New is simply an acceptance of the request, but not necessarily mean it is confirmed into order book.

The drop copy subscription can be used to check when the order is successfully cancelled.

See FIX Spot Order Life Cycle and ExecutionReport for details.

Response Attributes

An ExecutionReport (8) with ExecType=6 (Pending Cancel) for acceptance of the cancel request, pending for confirmation. Besides, OrderCancelReject (9) can be returned if cancel reject happens.

See FIX Spot Order Life Cycle, ExecutionReport and OrderCancelReject for details.

OrderCancelReject (35=9)

The Order Cancel Reject <9> message is issued by the broker upon receipt of a cancel request or cancel/replace request message which cannot be honored. Requests to change price or decrease quantity are executed only when an outstanding quantity exists. Filled orders cannot be changed (i.e quantity reduced or price change. However, the broker/sellside may support increasing the order quantity on a currently filled order).

When rejecting a Cancel/Replace Request (or Cancel Request ), the Cancel Reject <9> message should provide the ClOrdID <11> which was specified on the Cancel/Replace Request (or Cancel Request) message for identification, and the OrigClOrdId should be that of the last accepted order (except in the case of CxlRejReason <102> = "Unknown Order".

OrderMassCancelRequest (35=q)

Cancels all orders for a particular instrument/pair (asynchronous)

This call is asynchronous, so the response as OrderMassCancelReport is simply an acceptance of the request, but not necessarily mean it is confirmed into order book.

The drop copy subscription can be used to check when the order is successfully cancelled with ExecutionReport or rejected with OrderCancelReject message.

From the drop copy, for each respective order, Execution Report (8) with ExecType=6 (Pending Cancel) and/or ExecType=4 (Cancelled) for acceptance and confirmation of the cancel request respectively. Besides, OrderCancelReject (9) can be returned if cancel reject happens.

Response Attributes

See OrderMassCancelReport for details

OrderMassCancelReport (35=r)

The Order Mass Cancel Report is used to acknowledge an Order Mass Cancel Request . Note that each affected order that is canceled is acknowledged with a separate Execution Report <8> or Order Cancel Reject <9> message.

MassOrder (35=DJ)

The MassOrder message, which we adopted from FIX 5.0 SP2, can be used to add or cancel multiple unrelated orders with a single message. Only the key order attributes for high performance trading are available.

The behaviour of individual orders within a MassOrder (35=DJ) may vary depending upon its attributes, e.g. OrdType (40) and TimeInForce (59). Individual orders may be cancelled with single order messages such as OrderCancelRequest. Each of the orders in the MassOrder (35=DJ) are to be treated as stand-alone individual orders.

Response Attributes

MassOrder sends 35=D or 35=F in batch respectively. Each order will follow their respective execution report. See ExecutionReport for details.

ExecutionReport (35=8)

ExecType values

The ExecType (150) field indicates the reason why this ExecutionReport was sent.

OrderStatusRequest (35=H)

Get details on a particular OPEN Orders only.

Response Attributes

An ExecutionReport (8) with ExecType=I (Order Status) will be returned.

* Order status request rejected for unknown order

See ExecutionReport for details.

MarketDataRequest (35=V)

Subscribes to Market Data: Order Book, Trades.

Response Attributes

See MarketDataIncrementalRefresh and MarketDataRequestReject for details.

MarketDataIncrementalRefresh (35=X)

Response for Market Data Request.

MarketDataRequestReject (35=Y)

The Market Data Request Reject is used when the broker cannot honor the Market Data Request , due to business or technical reasons. Brokers may choose to limit various parameters, such as the size of requests, whether just the top of book or the entire book may be displayed, and whether Full or Incremental updates must be used.

SecurityDefinitionRequest (35=c)

The FIX Client could request the details of a tradable instrument by sending a Security Definition Request (35=c) message to the gateway. The Symbol (55) is used as the unique identifier of an instrument.

Response Attributes

See SecurityDefinition for details.

SecurityDefinition (35=d)

After received 35=c, gateway will acknowledge and send a Security Definition (35=d) message to the client. The subscribed clients will be sent a Security Definition (35=d) message for each new instrument. Client will receive multiple Security Definition (35=d) when receiving (35=c,321=3)

Snapshot/Full Refresh (35=W)

The Market Data messages are used as the response to a Market Data Request 'V' message. In all cases, one Market Data message refers only to one Market Data Request 'V'. It can be used to transmit a 2-sided book of orders or list of quotes, a list of trades, index values, opening, closing, settlement, high, low, or VWAP prices, the trade volume or open interest for a security, or any combination of these.

SecurityListRequest (35=x)

Security List is an aggregation of instrument definitions. It is useful when the FIX Client want get all instrument definitions, or expect to get numerous instrument definitions in one go. The FIX Client should send a Security List Request (35=x) message to the gateway.

Response Attributes

See SecurityList for details.

SecurityList (35=y)

After receiving 35=x, the Gateway will acknowledge this message by sending one or more Security List (35=y) message, because the gateway divides the list of instruments into chunks, and each chunk will construct a Security List (35=y) message so as to avoid an excessively large Security List (35=y) message. The subscribed clients will be sent a Security Definition (35=d) message for each new instrument. ie. One instrument with one 35=y only.

BusinessMessageReject (35=j)

The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means.