ATS Connectivity Specification

Specifications for ATS Connectivity

Introduction

1. 1. FIX for Market Data
   1. 1.1. Disclaimer and Rights Granted
   2. 1.2. Overview
   3. 1.3. Data Types
   4. 1.4. Symbology
   5. 1.5. Recovery
   6. 1.6. Standard Header/Trailer
      1. 1.6.1. Message Header
      2. 1.6.2. Message Trailer
   7. 1.7. Session Messages
      1. 1.7.1.Heartbeat (MsgType = 0)
      2. 1.7.2. Logon (MsgType = A)
      3. 1.7.3. Test Request (MsgType = 1)
      4. 1.7.4. Resend Request (MsgType = 2)
      5. 1.7.5. Reject (Msg Type = 3)
      6. 1.7.6. Sequence Reset (MsgType = 4)
      7. 1.7.7. Logout (MsgType = 5)
      8. 1.7.8. Market Data Request (MsgType = V)
   8. 1.8. Example FIX Message
   9. 1.9. Example FIX Message
   10. 1.10. Example FIX Message
2. 2. FIX for Order Routing
   1. 2.1. Disclaimer and Rights Granted
   2. 2.2. Overview
   3. 2.3. Supported Order Types
   4. 2.4. Symbology
   5. 2.5 Connecting to Coinsquare FIX
      1. 2.5.1 Physical Connection
      2. 2.5.2. Login Credentials and Connection Procedures
   6. 2.6. FIX Messages
      1. 2.6.1. FIX messages supported
   7. 2.7. Custom Fix Tags
   8. 2.8. FIX Message Header & Trailer
      1. 2.8.1. Message Header
      2. 2.8.2. Message Trailer (All)
   9. 2.9. Drop Copy Sessions
   10. 2.10. Administrative Messages
       1. 2.10.1. Heartbeat (MsgType = 0)
       2. 2.10.2. Logon (MsgType = A)
       3. 2.10.3. Test Request (MsgType = 1)
       4. 2.10.4. Resend Request (MsgType = 2)
       5. 2.10.5. Reject (Msg Type = 3)
       6. 2.10.6. Sequence Reset (MsgType = 4)
       7. 2.10.7. Logout (MsgType = 5)
   11. 2.11. Application Messages – Customer
       1. 2.11.1. New Order – Single (MsgType = D)
       2. 2.11.2. Order Cancel Request (MsgType = F)
   12. 2.12. Application Messages – Coinsquare ATS to customer
       1. 2.12.1. Execution Report  (MsgType 8)
3. 3. Websocket API
   1. 3.1 Overview
   2. 3.2. Rate Limits
   3. 3.3. Time Format
   4. 3.4. Connectivity
      1. 3.4.1. Example Structure:  JAVA Script
   5. 3.5. Market Data
      1. 3.5.1. Get Symbols
      2. 3.5.2. Example Structure:  JAVA Script
   6. 3.6. Subscribe Order Book
      1. 3.6.1. Example Structure:  JAVA Script
   7. 3.7. Subscribe Live Trades
      1. 3.7.1. Example Structure:  JAVA Script
   8. 3.8. Query Trade History
      1. 3.8.1. Example Structure:  JAVA Script
   9. 3.9. Query Aggregate Trade History
      1. 3.9.1. Example Structure:  JAVA Script
   10. 3.10. Subscribe Trading Pair Status
       1. 3.10.1 Example Structure:  JAVA Script
   11. 3.11. Subscribe High and Low Price
       1. 3.11.1. Example Structure:  JAVA Script
   12. 3.12. Authentication
       1. 3.12.1. Example Structure:  JAVA Script
   13. 3.13. Login
       1. 3.12.1. Example Structure:  JAVA Script
   14. 3.14. Logout
       1. 3.14.1. Example Structure:  JAVA Script
   15. 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:

1. FIX for Market Data
2. FIX for Order Routing
3. 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.

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

1.6.2. Message Trailer

 

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.

 

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:

1. 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.
2. Handle retransmission requests
3. Initiate a Logon using the SenderCompID in the message header.
4. Will forwarded to the FIX client messages that are waiting in the outbound queue.
5. Begin regular message communication.

 

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.

 

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.

 

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.

 

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:

1. Sequence Reset-GapFill – GapFillFlag=Y
2. 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.

 

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:

1. 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.

 

Note: Logout is not required.

Application Messages – Customer to MPID

1.7.8. Market Data Request (MsgType = V)

 

 

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)

 

 

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)

 

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)

 

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.

 

2.4. Symbology

For inbound FIX message to Market Participant Identity (MPID), we expect customers to send root symbol in tag 55.

 

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.  

 

1. The client establishes a TCP connection through a proprietary or commercial FIX engine using the assigned destination IP address and port.
2. 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.
3. 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)
4. 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.
5. 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:

 

2.7. Custom Fix Tags

The following list of FIX tags that extend the FIX 4.2 protocol.  

 

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

 

 

2.8.2. Message Trailer (All)

All messages are to contain the following required tags in the trailer.

 

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.

 

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:

1. Initiate retransmission processing via a resend request if the Logon sequence number is greater than the value expected
2. 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.
3. Handle retransmission requests
4. Initiate a Logon using the SenderCompID in the message header.
5. Will forwarded to the FIX client messages that are waiting in the outbound queue  
6. Begin regular message communication.

 

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.

 

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.

 

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.

 

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:

1. Sequence Reset-GapFill – GapFillFlag=Y
2. 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.

 

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:

1. A confirming logout message will be sent by the gateway to the client; then,
2. The session will be disconnected.

The FIX gateway should never initiate a logoff except when a severe error has occurred.

 

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.

 

2.11.2. Order Cancel Request (MsgType = F)

 

2.12. Application Messages – Coinsquare ATS to customer

2.12.1. Execution Report  (MsgType 8)

 

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.

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.

 

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.

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.

                                                                                           

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

           

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.

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.

 

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.

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.

 

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”}