https://d33wubrfki0l68.cloudfront.net/9c6282ad47728686af5e3c9dacaa8fb19a8ed32e/e75ee/static/696015a52a9b7e368847be3ae56d0687/company-logo-black.svg
https://d33wubrfki0l68.cloudfront.net/9c6282ad47728686af5e3c9dacaa8fb19a8ed32e/e75ee/static/696015a52a9b7e368847be3ae56d0687/company-logo-black.svg
Products
Trade

Buy, sell or HODL Bitcoin and more

Pro

Advanced crypto trading platform

Wealth

Get personalized service from our wealth experts

About
Who we are
Blog
Regulation
CoinsSupport
Sign inGet started

ATS Connectivity Specification

April 12, 2022

Specifications for ATS Connectivity

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.

 

Security
Categorization

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:

  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.

 

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:

  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.

 

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:

  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.

 

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:

  1. = Bid
  2. = Offer

->

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:

  1. = Bid
  2. = Offer

->

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
Asset Pairs

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

  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:

 

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:

  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.

 

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:

  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.

 

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:

  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.

 

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 asset

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.

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

https://d33wubrfki0l68.cloudfront.net/9c6282ad47728686af5e3c9dacaa8fb19a8ed32e/e75ee/static/696015a52a9b7e368847be3ae56d0687/company-logo-black.svg
Product
ATS
Legal and Regulatory Documents
Fees
Client Account Agreement
Privacy Policy
Services
Coinsquare Status
Sitemap
Company
Contact us
Help
Who we are
Blog
Careers
Regulatory Status
Cookie policy
How to buy Bitcoin
How to buy Ethereum
Like Coinsquare on FacebookFollow Coinsquare on TwitterFollow Coinsquare on InstagramConnect with Coinsquare on LinkedInFollow Coinsquare on Reddit
© Coinsquare 2022

Property as prescribed in the Coverage Policy of the Canadian Investor Protection Fund (CIPF) that is held in customers’ accounts, including cash balances but not crypto assets, is protected by CIPF within specified limits. A brochure describing the nature and limits of coverage is available upon request or at https://www.cipf.ca.

FINTRAC Registered