ATS Connectivity Specification
Specifications for ATS Connectivity
- 1. FIX for Market Data
- 2. FIX for Order Routing
- 2.1. Disclaimer and Rights Granted
- 2.2. Overview
- 2.3. Supported Order Types
- 2.4. Symbology
- 2.5 Connecting to Coinsquare FIX
- 2.6. FIX Messages
- 2.7. Custom Fix Tags
- 2.8. FIX Message Header & Trailer
- 2.9. Drop Copy Sessions
- 2.10. Administrative Messages
- 2.11. Application Messages – Customer
- 2.12. Application Messages – Coinsquare ATS to customer
- 3. Websocket API
- 3.1 Overview
- 3.2. Rate Limits
- 3.3. Time Format
- 3.4. Connectivity
- 3.5. Market Data
- 3.6. Subscribe Order Book
- 3.7. Subscribe Live Trades
- 3.8. Query Trade History
- 3.9. Query Aggregate Trade History
- 3.10. Subscribe Trading Pair Status
- 3.11. Subscribe High and Low Price
- 3.12. Authentication
- 3.13. Login
- 3.14. Logout
- Error parsing json
Introduction
Coinsquare ATS is accessible to subscribers via FIX (Financial Information Exchange) and Websocket API. This documents outlines the specifications for three separate connection types:
- FIX for Market Data
- FIX for Order Routing
- Websocket API
1. FIX for Market Data
1.1. Disclaimer and Rights Granted
The information contained in this document describing Coinsquare Ltd. implementation of the FIX protocol and any other information or documentation related to Coinsquare ATS Market Data FIX Specifications message formats are provided “as is”, and neither Coinsquare ATS nor any of its affiliates makes any representation or warranty, express or implied, as to the contents of the Coinsquare ATS Market Data FIX Specifications and each such person specifically disclaims any warranty of originality, accuracy, completeness, merchantability, fitness for a particular purpose or that it is error-free. By using the Coinsquare ATS Market Data FIX Specifications, you are agreeing to assume the entire risk associated with its use.
The Coinsquare ATS shall have no liability for damages of any kind arising in any manner out of or in connection with your use of, or your inability to use, the Coinsquare ATS Market Data FIX Specifications, whether direct, indirect, incidental, special or consequential arising under contract or otherwise, whether or not Coinsquare ATS or any of its affiliates has been advised of, or otherwise might have anticipated the possibility of, such damages.
Please note that Coinsquare ATS will require prior certification of any system designed to connect to its trading and market information as well as your participation from time to time in connection with the testing of changes or upgrades to Coinsquare ATS Market Data FIX Specifications.
The information contained in the Coinsquare ATS Market Data FIX Specifications is proprietary and confidential information belonging to Coinsquare ATS and Fix Protocol Limited and/or their respective licensors or service providers, as applicable. Copyright and trade-mark rights and any other intellectual property in the Coinsquare ATS Market Data FIX Specifications belong to the Fundamental Interactions, FIX Protocol Limited and/or its licensors or service providers, as applicable. Your permitted use of the Coinsquare ATS Market Data FIX Specifications, in whole or in part, is limited to the non-exclusive, non-transferable, revocable, non-assignable, personal right for you only to build a connection between your systems and Coinsquare ATS trading system.
Copyright in the Coinsquare ATS Market Data FIX Specifications belongs Coinsquare Ltd., 2021. All rights reserved.
Copyright in the FIX Protocol belongs to FIX Protocol Limited: www.fixprotocol.org. FIX Protocol content, documents, information and materials are used solely with permission of FIX Protocol Limited.
1.2. Overview
The information in this FIX document describes the adaptation of the standard FIX 4.2 for vendors and subscribers to communicate with the Coinsquare ATS quotation and execution ATS. FIX 4.2 tags, as described in detail on the Financial Information Exchange Protocol Committee website, www.fixprotocol.org as well as custom tags are used extensively in this document and the reader should familiarize themselves with the latest updates to this release.
If an application message in Financial Information Exchange Protocol version 4.2, or previous FIX versions, is not included in this document, the message is ignored by MPID.
1.3. Data Types
All FIX timestamps are GMT as per FIX standard. Clients are expected to synchronize their clocks with an external time source.
Prices – Clients should program their systems to allow execution prices to be returned with up to six decimals
1.4. Symbology
For inbound FIX message to MPID, the symbology. When using CMS format, we expect customer to send root symbol in tag 55. When using symbology, we expect customer to send everything in tag 55.
Security |
Symbol |
---|---|
Bitcoin in CAD$ |
BTCCAD |
Ethereum in CAD$ |
ETHCAD |
1.5. Recovery
The MPID FIX market data feed provides a primary and secondary site for customer to connect. Two sites are synced in real time, so the session info (such as incoming/outgoing sequence number, etc…) is kept at both sites.
Only one site is active at any time. The inactive site will reject socket connection attempts.
When initiating the connection, customer’s process should first attempt primary site, if fails, then attempt secondary site, and so on…
1.6. Standard Header/Trailer
1.6.1. Message Header
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
8 |
BeginString |
Y |
“FIX.4.2” |
9 |
BodyLength |
Y |
(Always unencrypted, must be second field in message) |
35 |
MsgType |
Y |
(Always unencrypted, must be third field in message) |
49 |
SenderCompID |
Y |
Provided by MPID system administrator, must be specified in all FIX messages to MPID, will be echoed back in TargetCompID in all FIX messages to customers. |
56 |
TargetCompID |
Y |
Provided by customer, always echoed back in SenderCompID in all FIX messages to customers. |
115 |
OnBehalfOfCompID |
N |
Required for service bureau connection |
34 |
MsgSeqNum |
Y |
(Can be embedded within encrypted data section.) |
43 |
PossDupFlag |
N |
Always required for retransmitted messages, whether prompted by the sending system or as the result of a resend request. (Can be embedded within encrypted data section.) |
97 |
PossResend |
N |
Ignored by MPID |
52 |
SendingTime |
Y |
Required |
122 |
OrigSendingTime |
N |
Required for message resends. If data is not available set to same value as SendingTime (Can be embedded within encrypted data section.) |
1.6.2. Message Trailer
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
10 |
CheckSum |
Y |
(Always unencrypted, always last field in message) |
1.7. Session Messages
1.7.1.Heartbeat (MsgType = 0)
This message is intended to monitor the status of the communications link during periods of inactivity.
The FIX market data accepts and generates Heartbeat messages as per the FIX specification.
- Inbound: Handled as specified
- Outbound: In response to a test request or timeout.
- Response: None
The heartbeat message should be sent if agreed upon Heartbeatinterval has elapsed since the last message sent. If any proceeding Heartbeatinterval a Heartbeat message need not be sent.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = 0 |
112 |
TestReqID |
N |
Required when the heartbeat is the result of a Test Request message. |
|
Standard Trailer |
Y |
|
1.7.2. Logon (MsgType = A)
The logon message identifies and authenticates the user or member and establishes a connection to the FIX Gateway. The FIX gateway accepts Logon messages as per the FIX specification. Further, the FIX gateway supports the logon sequence required for session authentication. After a successful logon as described in the specification the FIX gateway will:
- Initiate retransmission processing via a resend request if the Logon sequence number is greater than the value expected Initiate logout processing via a Logout message with an appropriate error message, then waits for a confirming Logout before disconnecting if the Logon sequence number is less than expected. If the confirming Logout has not been received within a short period of time the session will be disconnected.
- Handle retransmission requests
- Initiate a Logon using the SenderCompID in the message header.
- Will forwarded to the FIX client messages that are waiting in the outbound queue.
- Begin regular message communication.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = A |
108 |
HeartBtInt |
Y |
Heartbeat interval in seconds |
|
Standard Trailer |
Y |
|
1.7.3. Test Request (MsgType = 1)
If a Heartbeatinterval + 1 second have elapsed since the last message received, a Test Request should be issued. If another Heartbeatinterval + 1 second go by without receiving a message, the TCP connection should be dropped.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = 1 |
112 |
TestReqID |
Y |
|
|
Standard Trailer |
Y |
|
1.7.4. Resend Request (MsgType = 2)
The resend request message initiates the retransmission of messages. The FIX client or Gateway may generate a resend request when a message sequence number gap is detected. Refer to the FIX protocol documentation for a full description of resend processing.
The FIX system handles resend requests conformant to the FIX protocol. Refer to the FIX 4.2 specification for details on resend processing.
A Resend Request message should be processed even if it is received ahead of sequence. Only after resending the request range (all marked PossDup= “Y”, including gap fills) should Resend Request issued in the opposite direction.
(All marked PossDup= “Y”, including gap fills) should Resend Request issued in the opposite direction.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = 2 |
7 |
BeginSeqNo |
Y |
|
16 |
EndSeqNo |
Y |
|
|
Standard Trailer |
Y |
|
1.7.5. Reject (Msg Type = 3)
This message is used by the FIX Gateway to reject messages that violate session level rules and are unable to be processed. The gateway checks inbound messages for the presence of its required tags. It also validates the message type tag session level rejects are used to indicate violations of the session protocol, or missing fields.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = 3 |
45 |
RefSeqNum |
Y |
MsgSeqNum of rejected message |
58 |
Text |
N |
Where possible, message to explain reason for rejection |
|
Standard Trailer |
Y |
|
1.7.6. Sequence Reset (MsgType = 4)
This message is used to reset the incoming sequence number of the opposing side. This message supports two modes:
- Sequence Reset-GapFill – GapFillFlag=Y
- Sequence Reset-Reset – GapFillFlag=N (Only used to recover from Disaster)
The GapFill can be used to mark a place of a message(s) or administration messages that are not being resent. To view the complete functionality of the Sequence Reset (Gap Fill) message refer to the FIX protocol.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = 4 |
123 |
GapFillFlag |
N |
Y=Gap fill beginning at NewSeqNo N=NewSeqNo is ignored – manual recovery attempted |
36 |
NewSeqNo |
Y |
Next requested sequence number |
|
Standard Trailer |
Y |
|
1.7.7. Logout (MsgType = 5)
The Logout message initiates or confirms the termination of a FIX session.
The FIX gateway will receive and generate logout messages as required by the FIX Protocol. The gateway follows the prescribed sequence of messages for the proper termination of the session.
Messages received by the gateway after the client logs out are stored in a log file for transmission to the client once the client logs in again within the same trading day. The messages to be transmitted are dependent on the sequence number reconciliation that occurs on a logon handshake.
Upon receipt of a Logout message:
- A confirming logout message will be sent by the gateway to the client; then, 3 The session will be disconnected.
The FIX gateway should never initiate a logoff except when a severe error has occurred.
Either side may issue a logout to close the session.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = 5 |
58 |
Text |
N |
|
|
Standard Trailer |
Y |
|
Note: Logout is not required.
Application Messages – Customer to MPID
1.7.8. Market Data Request (MsgType = V)
Tag |
Field Name |
Req’d |
Comments |
|
---|---|---|---|---|
|
Standard Header |
Y |
MsgType = V |
|
262 |
MDReqID |
Y |
Unique identifier for Market Data Request Must be unique, or the ID of previous Market Data Request to disable if SubscriptionRequestType = Disable previous Snapshot + Updates Request (2) |
|
263 |
SubscriptionRequestType |
Y |
Subscription Request Type Valid values: 1 = Snapshot + Updates (Subscribe) 2 = Disable previous Snapshot + Update Request (Unsubscribe) |
|
264 |
MarketDepth |
Y |
Depth of market for Book Snapshot The actual value is ignored. MPID reports top of book in snapshot, and reports full book in updates |
|
265 |
MDUpdateType |
N |
Specifies the type of Market Data update. The actual value is ignored. When a client subscribes, they will receive incremental refresh Valid values: 1 = Incremental Refresh |
|
266 |
AggregatedBook |
N |
Specifies whether or not book entries should be aggregated. The actual value is ignored. When a client subscribes, they will receive aggregated book. Valid values: Y = one book entry per side per price |
|
267 |
NoMDEntryTypes |
Y |
Number of MDEntryType fields requested. Actual values are ignored. When a client subscribes, they will receive bid/offer information |
|
-> |
269 MDEntryType |
Y |
Type of Market Data Entry the client wishes to receive. Actual value is ignored |
|
146 |
NoRelatedSym |
Y |
Number of symbols requested |
|
-> |
55 |
Symbol |
Y |
Must be the first field in the repeating group |
-> |
65 |
SymbolSfx |
N |
|
|
Standard Trailer |
Y |
|
1.8. Example FIX Message
A request for market data on symbol would appear as
8=FIX.4.29=12435=V49=TESTMD56=TEST34=352=20130819-
19:04:49262=35184372088833263=1264=0265=1266=Y267=2269=0269=1146=155=MSFT10=164
Application Messages –MPID to Customer
Market Data – Top of Book Snapshot (MsgType=W)
Tag |
Field Name |
Req’d |
Comments |
|
---|---|---|---|---|
|
Standard Header |
Y |
MsgType = W |
|
262 |
MDReqID |
Y |
The MDReqID of the MarketDataRequest message. |
|
55 |
Symbol |
Y |
Identifier for the symbol |
|
65 |
SymbolSfx |
N |
|
|
268 |
NoMDEntries |
Y |
Number of market data entries in this snapshot. |
|
-> |
269 |
MDEntryType |
Y |
Type of market data entry. Valid values:
|
-> |
270 |
MDEntryPx |
Y |
Price of the market data entry. |
-> |
271 |
MDEntrySize |
N |
Number of shares represented by the Market Data Entry. |
|
Standard Trailer |
Y |
|
1.9. Example FIX Message
In response to valid market data request, MPID will report the current best bid and offer in the market. The FIX message would appear as
8=FIX.4.29=13035=W49=TEST56=TESTMD34=352=20130819-
19:04:4955=MSFT268=2269=0270=30.01271=100269=1270=30.99271=100262=3518437208883310=18
6
Market Data – Incremental Refresh (MsgType=X)
Tag |
Field Name |
Req’d |
Comments |
|
---|---|---|---|---|
|
Standard Header |
Y |
MsgType = X |
|
262 |
MDReqID |
Y |
The MDReqID of the MarketDataRequest message. |
|
268 |
NoMDEntries |
Y |
Number of market data entries in this snapshot. |
|
-> |
279 |
MDUpdateAction |
Y |
The Market Data update action type. It must be the first field in the repeating group. The only valid values are 0 = New |
|
|
|
|
2 = Delete |
-> |
269 |
MDEntryType |
Y |
Type of market data entry. Valid values:
|
-> |
278 |
MDEntryID |
Y |
Market data identifier |
-> |
55 |
Symbol |
Y |
Identifier for the symbol |
-> |
270 |
MDEntryPx |
N |
Price of the market data entry |
-> |
271 |
MDEntrySize |
N |
Number of shares represented by the Market Data Entry |
-> |
387 |
TotalVolumeTraded |
N |
Trade only, number of shares traded for this security |
|
Standard Trailer |
Y |
|
1.10. Example FIX Message
In response to valid market data request, MPID will provide incremental updates. The FIX message would appear as
8=FIX.4.29=13635=X49=TEST56=TESTMD34=552=20130819-
19:05:40262=35184372088833268=1279=0269=0278=108086391056891905155=MSFT270=30.02271=5 0010=059
8=FIX.4.29=13435=X49=TEST56=TESTMD34=752=20130819-
19:05:57262=35184372088833268=1279=2269=0278=108086391056891905155=MSFT270=30.02271=0 10=224
Market Data Request Reject (MsgType=Y)
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
|
Standard Header |
Y |
MsgType = Y |
262 |
MDReqID |
Y |
The MDReqID of the MarketDataRequest message. |
58 |
Text |
N |
Reason for the rejection. |
|
Standard Trailer |
Y |
|
2. FIX for Order Routing
2.1. Disclaimer and Rights Granted
The information contained in this document describing Coinsquare Ltd. implementation of the FIX protocol and any other information or documentation related to Coinsquare ATS Market Data FIX Specifications message formats are provided “as is”, and neither Coinsquare ATS nor any of its affiliates makes any representation or warranty, express or implied, as to the contents of the Coinsquare ATS Market Data FIX Specifications and each such person specifically disclaims any warranty of originality, accuracy, completeness, merchantability, fitness for a particular purpose or that it is error-free. By using the Coinsquare ATS Market Data FIX Specifications, you are agreeing to assume the entire risk associated with its use.
The Coinsquare ATS shall have no liability for damages of any kind arising in any manner out of or in connection with your use of, or your inability to use, the Coinsquare ATS Market Data FIX Specifications, whether direct, indirect, incidental, special or consequential arising under contract or otherwise, whether or not Coinsquare ATS or any of its affiliates has been advised of, or otherwise might have anticipated the possibility of, such damages.
Please note that Coinsquare ATS will require prior certification of any system designed to connect to its trading and market information as well as your participation from time to time in connection with the testing of changes or upgrades to Coinsquare ATS Market Data FIX Specifications.
The information contained in the Coinsquare ATS Market Data FIX Specifications is proprietary and confidential information belonging to Coinsquare ATS and Fix Protocol Limited and/or their respective licensors or service providers, as applicable. Copyright and trade-mark rights and any other intellectual property in the Coinsquare ATS Market Data FIX Specifications belong to the Fundamental Interactions, FIX Protocol Limited and/or its licensors or service providers, as applicable. Your permitted use of the Coinsquare ATS Market Data FIX Specifications, in whole or in part, is limited to the non-exclusive, non-transferable, revocable, non-assignable, personal right for you only to build a connection between your systems and Coinsquare ATS trading system.
Copyright in the Coinsquare ATS Market Data FIX Specifications belongs Coinsquare Ltd., 2021. All rights reserved.
Copyright in the FIX Protocol belongs to FIX Protocol Limited: www.fixprotocol.org. FIX Protocol content, documents, information and materials are used solely with permission of FIX Protocol Limited.
2.2. Overview
The information in this FIX document describes the adaptation of the standard FIX 4.2 for vendors and subscribers to communicate with the Coinsquare ATS quotation and execution ATS. FIX 4.2 tags, as described in detail on the Financial Information Exchange Protocol Committee website, www.fixprotocol.org as well as custom tags are used extensively in this document and the reader should familiarize themselves with the latest updates to this release.
If an application message in Financial Information Exchange Protocol version 4.2, or previous FIX versions, is not included in this document, the message is ignored by MPID.
2.3. Supported Order Types
Coinsquare ATS currently supports limit order types.
Order Type |
Description |
---|---|
Limit Order |
A limit order is an order to buy or sell an asset at a specific price or better. A buy limit order can only be executed at the limit price or lower, and a sell limit order can only be executed at the limit price or higher. A limit order can only be filled if the asset price reaches the limit price. |
2.4. Symbology
For inbound FIX message to Market Participant Identity (MPID), we expect customers to send root symbol in tag 55.
Security |
Symbol examples |
---|---|
Bitcoin in CAD |
BTCCAD |
Ethereum in CAD |
ETHCAD |
Solana in CAD |
SOLCAD |
2.5 Connecting to Coinsquare FIX
2.5.1 Physical Connection
Connections to Coinsquare FIX are established through direct connections. Coinsquare staff will assign IP address and port numbers for connectivity to Coinsquare ATS FIX through your communications provider.
2.5.2. Login Credentials and Connection Procedures
IP address, port number, SenderCompID and TargetCompID are required to establish a connection. The ID assigned to each subscriber is used in the client message header as SenderCompID.
IP Address |
Assigned by Staff |
Validated during initial connection |
---|---|---|
Port |
Assigned by Staff |
Validated during initial connection |
SenderCompID |
Assigned by Staff |
Validated upon TCP connectivity |
TargetCompID |
Assigned by Staff |
Validated upon TCP connectivity |
- The client establishes a TCP connection through a proprietary or commercial FIX engine using the assigned destination IP address and port.
- The incoming IP address and port are examined, and connectivity is established upon successful validation. The connection is refused if the credentials do not pass validation.
- The logon message is the first message Coinsquare FIX expects to receive after TCP connectivity. (See the format of the Logon message in section 3 below)
- SenderCompID and TargetCompID received in the logon header message is examined and connectivity to the FIX gateway is established upon validation. The TCP connection is terminated if these credentials do not pass validation.
- FIX responds with a Logon acknowledge message upon establishing a successful session.
2.6. FIX Messages
This section outlines the FIX messages, how they are supported, and to what extent the business data is translated within the FIX Gateway.
2.6.1. FIX messages supported
The following FIX messages are supported by the FIX Gateway:
Message Category |
Message Name |
Message Type |
Message Direction |
Message Function |
---|---|---|---|---|
Administrative |
Heartbeat |
0 |
Inbound Outbound |
Monitors FIX gateway status during periods of inactivity |
Administrative |
Logon |
A |
Inbound Outbound |
Identifies and authenticates a user/ member establishing a connection to the FIX gateway. |
Administrative |
Test Request |
1 |
Inbound Outbound |
Verifies communications line and other FIX gateway parameters. |
Administrative |
Resend Request |
2 |
Inbound Outbound |
Initiates a re-transmission of messages from the FIX gateway. |
Administrative |
Reject |
3 |
Inbound Outbound |
Rejects messages that cannot be processed by the FIX gateway. |
Administrative |
Sequence Reset (Gap Fill) |
4 |
Inbound Outbound |
Message has two modes: Sequence Reset – Gap Fill and Sequence ResetReset. Sequence Reset Gap Fill – used to fill or mark the gap Sequence Reset – Reset – used to force synchronization |
Administrative |
Logout |
5 |
Inbound Outbound |
Used to terminate a FIX session. |
Customer |
New Order – Single |
D |
Inbound Outbound |
Submits a market or limit priced bid or offer order for a security listed within a market. May contain time in force terms such as day, open, good til date. |
ATS to Customer |
Execution Report |
8 |
Outbound |
|
|
Don’t Know Trade |
Q |
Inbound |
Rejects an execution report that was processed and sent by the FIX gateway. |
Customer |
Order Cancel Request |
F |
Inbound |
Request to cancel an order. |
|
Order Cancel Reject |
9 |
Outbound |
Reject message for an Order Cancel / Replace Request or Order Cancel Request that cannot be processed by the FIX gateway. |
|
Order Status Request |
H |
Inbound |
Request for querying the details of an order. |
|
Business Message Reject |
J |
Outbound |
Rejects any message that cannot be processed by the FIX gateway and is cannot be rejected via another message. |
2.7. Custom Fix Tags
The following list of FIX tags that extend the FIX 4.2 protocol.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
6750 |
Account Type |
N |
CL (Client) NC (Non-Client or Pro) IN (Inventory/Principal) |
7713 |
No Self Trade Feature |
Y |
2 character self-trade prevention NM (default) |
7714 |
No Self Trade Key |
Y |
This key prevents the order from trading against orders with the same key value. |
43211 |
Execution Venue |
No |
Specify where the trade happens, can be different from 43210, for example, “CROX” |
43212 |
Execution Contra Broker |
No |
MPID specific tag. Indicate who your contra broker here is. |
43214 |
Liquidity Indicator |
No |
Liquidity indicator. ‘P’, provided liquidity ‘T’, took liquidity |
43229 |
FractionBase |
Y |
If fraction typical value 100000000 |
2.8. FIX Message Header & Trailer
The message header and message trailer prefix and suffix all FIX messages. They contain the common information to uniquely identify and route the messages. Please refer to the description of each supported message to determine the required header and footer tags.
2.8.1. Message Header
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
8 |
BeginString |
Yes |
“FIX.4.2” |
9 |
BodyLength |
Yes |
(Always unencrypted, must be second field in message) |
35 |
MsgType |
Yes |
(Always unencrypted, must be third field in message) |
49 |
SenderCompID |
Ye |
Provided by MPID system administrator, must be specified in all FIX messages to Coinsquare ATS and it will be echoed back in TargetCompID in all FIX messages to customers. |
56 |
TargetCompID |
Yes |
Provided by customer, always echoed back in SenderCompID in all FIX messages to customers. |
115 |
OnBehalfOfCompID |
No |
Required for service bureau connection |
34 |
MsgSeqNum |
Yes |
(Can be embedded within encrypted data section.) |
43 |
PossDupFlag |
No |
Always required for retransmitted messages, whether prompted by the sending system or as the result of a resend request. (Can be embedded within encrypted data section.) |
97 |
PossResend |
No |
Ignored by MPID |
52 |
SendingTime |
Yes |
Required |
122 |
OrigSendingTime |
No |
Required for message resends. If data is not available ,set to same value as SendingTime (Can be embedded within encrypted data section.) |
2.8.2. Message Trailer (All)
All messages are to contain the following required tags in the trailer.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
10 |
CheckSum |
Yes |
(Always unencrypted, always last field in message) |
2.9. Drop Copy Sessions
The FIX Gateway offers Drop Copy sessions which provide copies of Execution Report messages that were originally sent to other FIX sessions from the same firm. These Drop Copy sessions must be pre-configured by Market Operations, and no special logon is required. All Administrative messages are supported on a Drop Copy session, and retransmission functions as per a regular FIX session.
When a Drop Copy session copies out an Execution Report to a client, this message will be indicated as a copy with CopyMsgIndicator = Y, as well as the OnBehalfOfCompID field providing the CompID of the FIX session to which the message was originally sent.
Execution Report messages where ExecType = 8 (Rejected) will not be copied out by a Drop Copy session. Any attempt by a client to submit an application message on a Drop Copy session will be rejected by the server.
2.10. Administrative Messages
The administrative messages are designed to meet the utility needs of the protocol. As a rule they contain no business information and consequently are handled internally within the FIX gateway. All administrative messages are supported.
Message |
MsgType |
Comments |
---|---|---|
Logon |
A |
This is sent after connection to identify and authenticate the customer and to establish a FIX session. |
Heartbeat |
0 |
Sent by FIX servers at predefined interval during login in tag 108. |
TestRequest |
1 |
This message will be sent if data has not been received for a within the specified HeartBeat interval. |
ResendRequest |
2 |
Notify the opposite party to resend messages that may have been missed. |
Reject Message |
3 |
Used in response to a message that could not be processed |
Sequence Reset |
4 |
Used to reset the FIX session sequence number |
Logout |
5 |
This is sent by the client to terminate the FIX session and perform a clean disconnect. |
2.10.1. Heartbeat (MsgType = 0)
The heartbeat message should be sent if agreed upon HeartbeatInterval has elapsed since the last message sent. If any proceeding HeartbeatInterval a Heartbeat message need not be sent.
2.10.2. Logon (MsgType = A)
The logon message identifies and authenticates the user or member and establishes a connection to the FIX Gateway.
The FIX gateway accepts Logon messages as per the FIX specification. Further, the FIX gateway supports the logon sequence required for session authentication.
After a successful logon as described in the specification the FIX gateway will:
- Initiate retransmission processing via a resend request if the Logon sequence number is greater than the value expected
- Initiate logout processing via a Logout message with an appropriate error message, then waits for a confirming Logout before disconnecting if the Logon sequence number is less than expected. If the confirming Logout has not been received within a short period of time the session will be disconnected.
- Handle retransmission requests
- Initiate a Logon using the SenderCompID in the message header.
- Will forwarded to the FIX client messages that are waiting in the outbound queue
- Begin regular message communication.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = A |
108 |
HeartBtInt |
Yes |
Heartbeat interval in seconds |
|
Standard Trailer |
Yes |
|
2.10.3. Test Request (MsgType = 1)
This message requests the return of a heartbeat message and verifies the communications line and other FIX parameters.
Inbound test request messages result in the appropriate heartbeat response.
If a Heartbeatinterval + 1 second has elapsed since the last message received, a Test Request should be issued. If another Heartbeatinterval + 1 second goes by without receiving a message, the TCP connection should be dropped.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = 1 |
112 |
TestReqID |
Yes |
Identifier included in Test Request message to be returned in resulting Heartbeat |
|
Standard Trailer |
Yes |
|
2.10.4. Resend Request (MsgType = 2)
The resend request message initiates the retransmission of messages. The FIX client or Gateway may generate a resend request when a message sequence number gap is detected.
A Resend Request message should be processed even if it is received ahead of sequence. Only after resending the request range (all marked PossDup= “Y”, including gap fills) should Resend Request issued in the opposite direction.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = 2 |
7 |
BeginSeqNo |
Yes |
Message sequence number of first record in range to be resent |
16 |
EndSeqNo |
Yes |
Message sequence number of last record in range to be resent. If request is for a single record BeginSeqNo = EndSeqNo. If request is for all messages subsequent to a particular message, EndSeqNo = 0 |
2.10.5. Reject (Msg Type = 3)
This message is used by the FIX Gateway to reject messages that violate session level rules and are unable to be processed. The gateway checks inbound messages for the presence of its required tags. It also validates the message type tag. In the case where the message type is missing (tag 35 on the inbound message), the reject message issues a value of “Unknown” in tag 58, as the FIX gateway is unaware of what the message is.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = 3 |
45 |
RefSeqNum |
Yes |
MsgSeqNum of rejected message |
58 |
Text |
No |
Where possible, message to explain reason for rejection |
2.10.6. Sequence Reset (MsgType = 4)
This message is used to reset the incoming sequence number of the opposing side. This message supports two modes:
- Sequence Reset-GapFill – GapFillFlag=Y
- Sequence Reset-Reset – GapFillFlag=N (only used to recover from Disaster)
The GapFill can be used to mark a place of a message(s) or administration messages that are not being resent. To view the complete functionality of the Sequence Reset (Gap Fill) message refer to the FIX protocol.
Tag |
Field Name |
Req’d |
Comments |
|
---|---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = 4 |
|
123 |
GapFillFlag |
No |
Y=Gap fill beginning at NewSeqNo N=NewSeqNo is ignored – manual recovery attempted |
|
36 |
NewSeqNo |
Yes |
Next requested sequence number |
|
|
Standard Trailer |
Yes |
|
2.10.7. Logout (MsgType = 5)
The Logout message initiates or confirms the termination of a FIX session.
The FIX gateway will receive and generate logout messages as required by the FIX Protocol. The gateway follows the prescribed sequence of messages for the proper termination of the session.
Messages received by the gateway after the client logs out are stored in a log file for transmission to the client once the client logs in again within the same trading day. The messages to be transmitted are dependent on the sequence number reconciliation that occurs on a logon handshake.
Upon receipt of a Logout message:
- A confirming logout message will be sent by the gateway to the client; then,
- The session will be disconnected.
The FIX gateway should never initiate a logoff except when a severe error has occurred.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = 5 |
58 |
Text |
No |
Free format text string (Note: this field does not have a specified maximum length) If the Logout message has been sent by the FIX gateway, then this field will contain the text “Session closed”. |
|
Standard Trailer |
Yes |
|
Note: Logout is not required.
2.11. Application Messages – Customer
2.11.1. New Order – Single (MsgType = D)
This message is used to submit an order to the trading system for processing.
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = D |
11 |
ClOrdID |
Yes |
Unique identifier of the order. Must be unique for each session, max 32 chars. |
1 |
Account |
No |
Optional identifier from customer, will be passed back in Execution Report Account mnemonic as agreed between broker and institution. |
18 |
ExecInst |
No |
Can contain multiple instructions, space delimited. G = All or None (AON)
|
21 |
HandInst |
No |
Handling Instructions 1 = Automated execution order, private no broker intervention |
55 |
Symbol |
Yes |
Ticker symbol. Common, “human understood” representation of the security. Examples: BTCCAD ETHCAD DOGECAD |
54 |
Side |
Yes |
1 = Buy 2 = Sell
|
38 |
OrderQty |
Yes |
Data type (Integer). This represents the number of coins to be traded. Multiplied by the fraction base. See FractionBase, tag 43229 |
43229 |
FractionBase |
Yes |
Fraction Order Qty, always set this value to 100,000,000. Eg. OrderQty = 1 implies 0.00000001 (0.00000001 * 100,000,000 = 1) |
40 |
OrdType |
Yes |
2 = Limit
|
44 |
Price |
No |
Conditional required for limit Order Type |
59 |
TimeInForce |
No |
1 = GTC (Good Till Cancel) 3 = IOC (Immediate-Or-Cancel) 4 = FOK (Fill or Kill)
|
47 |
Capacity |
No |
P = Principal A = Agency (Default) If not present, will use default account value |
6750 |
Account Type |
|
CL = Client NC = Non-Client (Default) IN = Inventory |
7713 |
NoTradeFeature |
Yes |
Self-trade prevention feature to prevent wash trades. Defines the behaviour of self-trade prevention when using NoTradeKey. NM = – (Default) 2 characters (not spaced): 1st character: N = Cancel newest order (the active order is canceled) 2nd character: M = Self-trade prevention at broker level (only orders with the same broker number will be prevented from trading) E – reduce order qty. (Do not use)
|
7714 |
NoTradeKey |
Yes |
This participant generated key prevents the order from trading against orders with the same key value. |
109 |
ClientID |
No |
Firm identifier used in third party-transactions. |
|
Standard Trailer |
Yes |
|
2.11.2. Order Cancel Request (MsgType = F)
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = F |
41 |
OrigClOrdID |
Yes |
ClOrdID of the previous order |
37 |
OrderID |
No |
Unique identifier of most recent order as assigned by broker. |
11 |
ClOrdID |
Yes |
Unique ID of cancel request as assigned by the institution. |
1 |
Account |
No |
Optional identifier of customer |
40 |
OrdType |
No |
|
55 |
Symbol |
Yes |
|
54 |
Side |
No |
‘1’ = Buy ‘2’ = Sell
|
38 |
OrderQty |
No |
|
47 |
|
|
|
58 |
Text |
No |
Free form text Field will be ignored |
59 |
TimeInForce |
No |
|
43229 |
FractionalBase |
No |
|
|
Standard Trailer |
Yes |
|
2.12. Application Messages – Coinsquare ATS to customer
2.12.1. Execution Report (MsgType 8)
Tag |
Field Name |
Req’d |
Comments |
---|---|---|---|
35 |
Standard Header |
Yes |
MsgType = 8 |
37 |
OrderID |
Yes |
System assigned order ID |
11 |
ClOrdID |
No |
Echo from Customer’s request |
41 |
OrigClOrdID |
No |
Echo from Customer’s request |
17 |
ExecID |
Yes |
System assigned execution ID Activity ID |
20 |
ExecTransType |
Yes |
|
19 |
ExecRefID |
No |
Required for Cancel and Correct ExecTransType messages |
150 |
ExecType |
Yes |
|
39 |
OrdStatus |
Yes |
0=New 1= PartiallyFilled 2=Filled 3=DoneForDay 4=Canceled 6=PendingCancel 7=Stopped 8=Rejected A=PendingNew C=Expired
|
1 |
Account |
No |
Copied from Customer’s request |
55 |
Symbol |
Yes |
Based on customer’s input.
|
54 |
Side |
Yes |
1 = Buy 2 = Sell
|
38 |
OrderQty |
Yes |
|
40 |
OrdType |
No |
2 = Limit
|
44 |
Price |
No |
Price per share |
59 |
TimeInForce |
No |
|
18 |
ExecInst |
No |
Can contain multiple instructions, space delimited. |
47 |
Capacity |
No |
Echo from Customer’s request |
32 |
LastQTY |
Yes |
Quantity of shares bought/sold on this (last) fill. |
31 |
LastPx |
Yes |
Price of this (last) fill. |
151 |
LeavesQty |
Yes |
Amount of shares open for further execution. |
14 |
CumQty |
Yes |
Currently executed shares for chain of orders. |
6 |
AvgPx |
Yes |
Calculated average price of all fills on this order. |
6750 |
Account Type |
No |
Echo from Customer’s request |
43211 |
Execution Venue |
No |
MPID specific tag. Example CROX |
43212 |
Execution Contra Broker |
No |
MPID specific tag.
|
43214 |
Liquidity Indicator |
No |
T – Taker P – Passive / Maker |
3. Websocket API
3.1 Overview
Welcome to API documentation. These documents outline trading platform functionality, market details, and APIs.
APIs are separated into two categories: Market data feed and trading. Feed APIs provide market data and are public. Trading APIs require authentication and provide access to placing orders and other account information.
3.2. Rate Limits
The API is rate limited to prevent abuse that would degrade our ability to maintain consistent API performance for all users.
WebSocket API
Public Endpoints
We throttle public endpoints by IP: 3 requests per second, up to 6 requests per second in bursts. Some endpoints may have custom rate limits.
Private Endpoints
We throttle private endpoints by user ID: 5 requests per second, up to 10 requests per second in bursts. Some endpoints may have custom rate limits.
3.3. Time Format
The API timestamp fields us the Epoch/POSIX format for WebSocket API Requests. Unix and POSIX measure time as the number of seconds that have passed since 1 January 1970 00:00:00 UTC
Do not provide milliseconds. ‘1614331055’ or ‘1614331055000’ are supported. ‘1614331055123’ is not supported.
3.4. Connectivity
The WebSocket market data feed provides real-time market data updates for orders and trades.
wss://ats-production.coinsquare.com:8081
For testing, use:
wss://exchange.fi.sandbox.coinsquarex.com:8081/
The WebSocket feed uses a bidirectional protocol, which encodes all messages as JSON objects. All messages have a type attribute that can be used to handle the message appropriately.
Please note that new message types can be added at any point in time. Clients are expected to ignore messages they do not support.
In the case of an initial connection failure, ensure to add the required certificates. Please follow the steps detailed in this knowledge base article – Adding the required SSL certificates.
3.4.1. Example Structure: JAVA Script
const WebSocket = require(‘ws’);
process.env[‘NODE_TLS_REJECT_UNAUTHORIZED’] = 0
const ws = new WebSocket(“wss://ws-sandbox.CoinSquare.com:8081/”)
ws.onopen = function() {
ws.send(JSON.stringify(
{
“type”: “TYPE”,
“request”: “REQUEST”
}
))
ws.onmessage = function(response) {
let websocket_response = JSON.parse(response.data);
console.log(websocket_response)
}
ws.close()
}
}
3.5. Market Data
3.5.1. Get Symbols
Category: Market Data
Permissions: Public
Endpoint: getsymbols
Retrieves the current assets and trading pairs on the platform.
Response |
Key |
Value |
---|---|---|
security |
string |
The trading pair or asset. |
fractionbase |
string |
The number of decimals supported. e.g 100 = 1.00 |
tradingsymbol |
string |
true if a trading pair, false if an assetFaux = actif |
pair_first |
string |
Specifies what the first asset is. e.g. LTC vs CAD |
fiat |
string |
true for fiat, false for virtual assets |
pair |
string |
true if a trading pair, false if an asset |
3.5.2. Example Structure: JAVA Script
# Request
{
“type”: “getsymbols”
}
# Response
{
“result”:”OK”,
“data”:[
{
“security”:”CAD”,
“fractionbase”:100,
“tradingsymbol”:false,
“fiat”:false,
“pair”:false
},
{
“security”:”LTCCAD”,
“fractionbase”:10000,
“pair_first”:”LTC”,
“tradingsymbol”:true,
“fiat”:false,
“pair_second”:”CAD”,
“pair”:true
},
{
“security”:”LTC”,
“fractionbase”:10000,
“tradingsymbol”:false,
“fiat”:false,
“pair”:false
},
{
“security”:”ETHCAD”,
“fractionbase”:100000,
“pair_first”:”ETH”,
“tradingsymbol”:true,
“fiat”:false,
“pair_second”:”CAD”,
“pair”:true
},
{
“security”:”ETH”,
“fractionbase”:100000,
“tradingsymbol”:false,
“fiat”:false,
“pair”:false
},
{
“security”:”BTCCAD”,
“fractionbase”:100000,
“pair_first”:”BTC”,
“tradingsymbol”:true,
“fiat”:false,
“pair_second”:”CAD”,
“pair”:true
},
{
“security”:”BTC”,
“fractionbase”:100000,
“tradingsymbol”:false,
“fiat”:false,
“pair”:false
},
{
“security”:”BCHCAD”,
“fractionbase”:100000,
“pair_first”:”BCH”,
“tradingsymbol”:true,
“fiat”:false,
“pair_second”:”CAD”,
“pair”:true
},
{
“security”:”BCH”,
“fractionbase”:100000,
“tradingsymbol”:false,
“fiat”:false,
“pair”:false
}
],
“type”:”getsymbols”
}
3.6. Subscribe Order Book
Category: Market Data
Permissions: Public
Endpoint: subscribe
Retrieves the latest order book information and then subscribes the user to ongoing market data event updates for the trading pairs specified.
The Subscribe call responds with the response shown below. Messages are then periodically sent in the same format as this response UpdateEvent information when best-bid/best-offer issue, until you close the connection.
Request |
Key |
Value |
Required |
---|---|---|---|
msg |
string |
Specify the type of data to subscribe to. use ‘book’ for order book data. |
Yes |
security |
string |
Specify the trading pair you wish to subscribe to. |
Yes |
dest |
string |
This value will always be set to CROX. |
Yes |
Response |
Key |
Value |
---|---|---|
security |
string |
The trading pair being subscribed to. |
side |
string |
The order side. |
act |
string |
The act to Update or Remove orders |
price |
string |
The price of the order. |
qty |
string |
The size of the order. |
time |
string |
The time of the order, in POSIX format. |
You can identify multiple trading pairs (security) by using ‘*”.
3.6.1. Example Structure: JAVA Script
# Request
{
“type”: “subscribe”,
“request”: [
{
“msg”:”book”,
“security”:”BCHCAD”,
“dest”:”CROX”
}
]
}
# Response
# order added
{
“security”:”BCHCAD”,
“books”:[
{
“side”:”B”,
“act”:”U”,
“src”:”CROX”,
“price”:”472.33″,
“qty”:”0.46″,
“id”:120947223715360,
“time”:”1626338416747″,
“mpid”:”ANON”,
“key”:”NA”
}
],
“type”:”book”
}
# order removed
{
“security”:”BCHCAD”,
“books”:[
{
“act”:”R”,
“id”:120947223715360,
“time”:”1626338444101″
}
],
“type”:”book”
}
3.7. Subscribe Live Trades
Category: Live Trades
Permissions: Public
Endpoint: subscribe
Retrieves the latest trade information and then subscribes the user to ongoing trade event updates for the specified trading pair.
The Subscribe call responds with the response shown below. TMessages are then periodically sent in the same format as this response until you close the connection.
Request |
Key |
Value |
Required |
---|---|---|---|
msg |
string |
Specify the type of data to subscribe to. use ‘trade’ for trade history data. |
Yes |
security |
string |
Specify the trading pair you wish to subscribe to. |
Yes |
dest |
string |
This value will always be set to CROX. |
Yes |
Response |
Key |
Value |
---|---|---|
security |
string |
The trading pair being subscribed to. |
src |
string |
The value will always be set to CROX. |
price |
string |
The price of the order. |
qty |
string |
The size of the order. |
time |
string |
The time of the order, in POSIX format. |
type |
string |
The nature of record. |
Matched |
string |
The exchange reference ID of the trade. |
You must specify a single trading pair for live trades.
3.7.1. Example Structure: JAVA Script
# Request
{
“type”: “subscribe”,
“request”: [
{
“msg”:”trade”,
“security”:”BCHCAD”,
“dest”:”CROX”
}
]
}
# Response
{
“security”:”BCHCAD”,
“src”:”CROX”,
“price”:”471.43″,
“qty”:”0.06969″,
“time”:”1626338546538″,
“type”:”trade”,
“matchid”:”62YNMDOQ2SPR”
}
3.8. Query Trade History
Category: Trade History
Permissions: Public
Endpoint: lshistory
The query returns trade history data will return data from the specified start time. The “total_rec” tells how many records there should be, and “rec_no” tell you the current number of record.
Request |
Key |
Value |
Required |
---|---|---|---|
type |
string |
Specify the type of data to subscribe to using ‘tradehistory’ for history data. |
Yes |
security |
string |
Specify the trading pair you wish to subscribe to. |
Yes |
starttime |
string |
Specify the start time in POSIX format. |
Yes |
Response |
Key |
Value |
---|---|---|
security |
string |
The trading pair being subscribed to. |
execprice |
string |
The price of the order. |
execqty |
string |
The size of the order. |
time |
string |
The time of the order, in POSIX format. |
rec_no |
int |
The record number. |
starttime |
string |
The start time of the window. |
total_rec |
string |
The total records displayed. |
You must specify a single trading pair for execution history.
3.8.1. Example Structure: JAVA Script
# Request
{
“type”:”lshistory”,
“security”:”ETHCAD”,
“starttime”:”1630530000000″
}
# Response
{
“result”: “OK”,
“security”: “LTCCAD”,
“data”:
[
{
“security”: “LTCCAD”,
“rec_no”: 1,
“execprice”: “182.51”,
“time”: “1630561535942”,
“execqty”: “0.5702”
}
],
“total_rec”: “1”,
“starttime”: “1630530000000”,
“type”: “lshistory”
}
3.9. Query Aggregate Trade History
Category: Trade History
Permissions: Public
Endpoint: tradehistory
The query returns the trade history in 1-minute block. If that minute has a trade, a corresponding block will be return with summary of that minute high/low/first/last trade price as well as volume and number of trades information.
There can be multiple responses to one query if there are more than 100 entries in response. Each response will carry maximum of 100 entries. “total_rec” tells how many records there should be, and “rec_no” tell you current number of record
Request |
Key |
Value |
Required |
---|---|---|---|
type |
string |
Specify the type of data to subscribe to using ‘tradehistory’ for trade history data. |
Yes |
security |
string |
Specify the trading pair you wish to subscribe to. |
Yes |
Response |
Key |
Value |
---|---|---|
security |
string |
The trading pair being subscribed to. |
price |
string |
The price of the order. |
qty |
string |
The size of the order. |
time |
string |
The time of the order, in POSIX format. |
numoftrades |
string |
The number of trades. |
lastttime |
string |
The last transaction time. |
blocktime |
string |
|
high price |
string |
The highest price of the window. |
lowprice |
string |
The Lowest price of the window. |
rec_no |
int |
The record number. |
starttime |
string |
The start time of the window. |
lastprice |
string |
The last price of the window. |
startprice |
string |
The start price of the window. |
total_rec |
string |
The total records displayed. |
You must specify a single trading pair for execution history.
3.9.1. Example Structure: JAVA Script
# Request
{
“type”: “tradehistory”,
“security”: “LTCCAD”
}
# Response
{
“result”:”OK”,
“security”:”LTCCAD”,
“data”:[
{
“volume”:”0.9375″,
“numoftrades”:”1″,
“lastttime”:”1630497372665″,
“blocktime”:”1630497360000″,
“highprice”:”174.69″,
“lowprice”:”174.69″,
“rec_no”:1,
“starttime”:”1630497372665″,
“lastprice”:”174.69″,
“startprice”:”174.69″
}
],
“total_rec”:”1″,
“type”:”tradehistory”
}
3.10. Subscribe Trading Pair Status
Category: Trading Pair Status
Permissions: Public
Endpoint: subscribesymbolstatus
Retrieves any changes to trading pair status. Values can be Halt, PreOpening or Normal..
The subscribesymbolstatus call responds with the responses shown below. Messages are sent anytime the status is updated.
Request |
Key |
Value |
Required |
---|---|---|---|
type |
string |
Specify the type of data subscribe to using ‘subscribesymbolstatus’ for symbol status data. |
Yes |
Response |
Key |
Value |
---|---|---|
security |
string |
The trading pair being subscribed to. |
time |
string |
The time of the order, in POSIX format. |
status |
string |
The new status for the trading pair. |
3.10.1 Example Structure: JAVA Script
# Request
{
“type”: “subscribesymbolstatus”
}
# Response
{
“result”:”OK”,
“type”:”subscribesymbolstatus”
}
# OR
{
“data”: [
{
“security”: “BCHCAD”,
“time”: “1623155345213”,
“status”: “Halt”
}
],
“type”: “symbolstatus”
}
# OR
{
“data”: [
{
“security”: “BCHCAD”,
“time”: “1623155345213”,
“status”: “PreOpening”
}
],
“type”: “symbolstatus”
}
# OR
{
“data”: [
{
“security”: “BCHCAD”,
“time”: “1623155345213”,
“status”: “Normal”
}
],
“type”: “symbolstatus”
}
3.11. Subscribe High and Low Price
Category: Market Data
Permissions: Public
Endpoint: subscribehighlow
Subscribes the user to ongoing market data event updates when there is a new high or low for the trading pairs specified. The time window 01:00 AM GST – 12:59 AM GST + 1
The subscribehighlow call responds with the response shown below. Messages are then periodically sent if there is a new high or low price.
Request |
Key |
Value |
Required |
---|---|---|---|
security |
string |
Specify the trading pair you wish to subscribe to. |
Yes |
Response |
Key |
Value |
---|---|---|
security |
string |
The trading pair being subscribed to. |
openingprice |
string |
The price at 01:01 AM or price after an opening price calculation. |
highprice |
string |
The highest execution price. |
lowprice |
string |
The lowest execution price. |
prevcloseprice |
string |
The execution price at 01:00 AM |
You can identify multiple trading pairs (security) by using ‘*”.
3.11.1. Example Structure: JAVA Script
# Request
{
“type”: “subscribehighlow”,
“security”: “*”
}
# Response
{
“security”: “BTCCAD”,
“prevcloseprice”: “35739.34”,
“type”: “highlow”
}
# OR
{
“openingprice”: “2388.1”,
“security”: “ETHCAD”,
“highprice”: “2388.1”,
“lowprice”: “2388.1”,
“prevcloseprice”: “2611.75”,
“type”: “highlow”
}
# OR
{
“result”: “OK”,
“security”: “*”,
“type”: “subscribehighlow”
}
3.12. Authentication
Category: Authentication
Permissions: Trading
Once client establishes the WebSocket connection, the client has 30 seconds to complete the login process. Otherwise, the socket will be closed by CoinSquare.
Challenge
First client needs to send a challenge request to the system.
Response |
Key |
Value |
---|---|---|
Key |
string |
The string used to encrypt the password |
The response contains a “key” field, which contains a public key string the client must use to encrypt the password field. The “key” field is a 64 base ASCII print out of the binary byte array for the corresponding public key of asymmetric public/ private key pair. CoinSquare will hold the private key while sending clients the public key. Client will first convert the ASCII back to binary byte array. Then use that binary byte array to create a “RSA” public key instance. Afterwards, client will use that RSA public key instance to encrypt info required in this order entry API, e.g. password encryption.
You need to use npm package to install jsencrypt library if you are using JavaScript.
3.12.1. Example Structure: JAVA Script
# Request
{
“type”: “challenge”
}
# Response
{
“result”:”OK”,
“type”:”challenge”,
“key”:”MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvBXTe278Lwg2MoI7iGKolSYuF+sNFKrsZplxCN9x0kItU3KIf8+1q60ILLwLewCEf7foxzpWp32j9YYU9vNBghuJ7BHcDYTffTRcv+QdNno491j701Hq7DIw13AGCQQTRcnfclvblnytIEWoQsiUvPJcdiWgqJIX3IQGA47a+uwIDAQAB”
}
global.window = {};
const JSEncrypt = require(“jsencrypt”);
key = response[‘key’];
const encrypt = new JSEncrypt();
encrypt.setPublicKey(key);
let sign = encrypt.encrypt(‘YOUR PASSPHRASE’);
3.13. Login
After encryption of password, the next step is to send in the login request. The string in the “pass” field is from the output result in sample above.
Request |
Key |
Value |
Required |
---|---|---|---|
userid |
string |
The username of the user. |
Yes |
pass |
string |
The pass phrase generated from the challenge and steps above. |
Yes |
Response |
Key |
Value |
---|---|---|
result |
string |
The response will either contain OK if successful or a rejection reason. |
CoinSquare ATS will send current open orders and position information upon login. If a user places a new order, CoinSquare ATS will send an order update automatically. If the user trades, they will receive a trade update and corresponding position updates.
3.12.1. Example Structure: JAVA Script
# Request
{
“type”:”login”,
“userid”:”USERNAME”,
“pass”:”s7UW26iGE/iVfk2ihPYIcyzRqZRi/Ztb23UNMomf3xrBzGKUHKzfNwZe5PIR/0zvfevYvkJnKLQVhR4U9/kObD/Ir0z6mBfLLgFwEcRm08jYI/nk7lDU+W32PqduTOCThlkXYueQslK54vR9rKvMs=”
}
# Response – You will get a ‘result’:’OK’
{
“result”:”OK”,
“firm”:”COIN”,
“need2FA”:true,
“roles”:”OOOOO”,
“active”:”Y”,
“secondary_account”:”TESEGY0101PGHA12345″,
“type”:”login”,
“attr”:
{
“country”:””,
“tax_code”:”SR”,
“last_name”:”USER”,
“first_name”:”USER “,
“email”:”user@mail.com”
},
“use2fa”:”Y”,
“userid”:”user@mail.com”,
}
# Any open orders will be returned as follows
{
“refno”:”62YNMDOQ2SPSC0″,
“side”:”B”,
“orderstatus”:”Open”,
“type”:”order”,
“userid”:”user@mail.com”,
“execamount”:”0″,
“tif”:”GTC”,
“firm”:”COIN”,
“security”:”BCHCAD”,
“price”:”471.43″,
“liveqty”:”0.49031″,
“qty”:”0.49031″,
“updtime”:”1626342626369″,
“enttime”:”1626342626366″,
“category”:”STAGE”,
“execqty”:”0″,
“account”:”user@mail.com”,
“ordertype”:”LMT”
}
# Your current positions will also be returned
{
“firm”:”COIN”,
“security”:”CAD”,
“curpos”:”1013057.59″,
“cost”:”-841663670.1899977″,
“type”:”position”,
“account”:”user@mail.com”
}
{
“firm”:”COIN”,
“security”:”BCH”,
“curpos”:”128.25376″,
“cost”:”12008212.15″,
“type”:”position”,
“account”:”user@mail.com”
}
{
“firm”:”COIN”,
“security”:”LTC”,
“curpos”:”121.7144″,
“cost”:”1199785.55″,
“type”:”position”,
“account”:”user@mail.com”
}
# OR
{
“result”:”invalid user/password”,
“type”:”login”
}
3.14. Logout
This is for clean logout. Once CoinSquare receives this message, it will immediately terminate the WebSocket connection.
3.14.1. Example Structure: JAVA Script
# Request
{
“type”:”logout”,
}
# Response
{
“result”:”OK”,
“type”:”logout”
}
Error parsing json
This error message indicates that there are typographical errors in your request.
Sample
{“result”:”error parsing json”}
Last Updated: October 12, 2022