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

Achetez, vendez ou conservez Bitcoin et plus

Pro

Plateforme avancée d’échange de cryptomonnaies

Wealth

Bénéficiez d’un service personnalisé de la part de nos experts en patrimoine.

À propos
Qui sommes-nous?
Blog
Régulation
DevisesAssistance
S'identifierDémarrer

Spécification de connectivité SNP

Comment se connecter à SNP

Introduction

  1. 1. Protocole FIX pour les données du marché
    1. 1.1. Disclaimer and Rights Granted
    2. 1.1 Clause de non-responsabilité et droits accordés
    3. 1.2 Sommaire
    4. 1.3 Types de données
    5. 1.4. Symbologie
    6. 1.5. Récupération
    7. 1.6. En-tête et fin de message standard
      1. 1.6.1. En-tête de message
      2. 1.6.2. Fin de message
    8. 1.7. Messages relatifs à la session
      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)
    9. 1.8. Exemple de message FIX
    10. 1.9. Exemple de message FIX
    11. 1.10. Exemple d’un message FIX
  2. 2. Protocole FIX pour le routage des ordres
    1. 2.1. Clause de non-responsabilité et droits accordés
    2. 2.2. Sommaire
    3. 2.3. Types d’ordres pris en charge
    4. 2.4. Symbologie
    5. 2.5 Se connecter à Coinsquare SNP
      1. 2.5.1 Connexion physique
      2. 2.5.2. Identification et procédure de connexion
    6. 2.6. Messages FIX
      1. 2.6.1. Messages FIX pris en charge
    7. 2.7. Tags FIX personnalisés
    8. 2.8. En-tête et fin de message FIX standard
      1. 2.8.1. En-tête de message
      2. 2.8.2. Fin de message
    9. 2.9. Sessions Drop Copy
    10. 2.10. Messages administratifs
      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. Messages de l’application – Client
      1. 2.11.1. Nouvel ordre – Single (MsgType = D)
      2. 2.11.2. Requête d’annulation d’ordre (MsgType = F)
    12. 2.12. Messages de l’application – De Coinsquare SNP au client
      1. 2.12.1. Rapport d’exécution  (MsgType 8)
  3. 3. Websocket API
    1. 3.1 Sommaire
    2. 3.2. Limitation de l’API
    3. 3.3. Format de l’heure
    4. 3.4. Connectivité
      1. 3.4.1. Exemple de structure :  script Java
  4. 3.5. Données sur le marché
    1. 3.5.1. Point de chute getsymbols
    2. 3.5.2. Exemple de structure :  script Java
  5. 3.6. Point de chute subscribe (registre des ordres)
    1. 3.6.1. Exemple de structure :  script Java
  6. 3.7. Point de chute subscribe (négociation en direct)
    1. 3.7.1. Exemple de structure :  script Java
  7. 3.8. Requête de l’historique de négociation
    1. 3.8.1. Exemple de structure :  script Java
  8. 3.9. Requête de l’historique de négociation complet
    1. 3.9.1. Exemple de structure :  script Java
  9. 3.10. Abonnement à l’état d’une paire négociée
    1. 3.10.1 Exemple de structure :  script Java
  10. 3.11. Abonnement pour les prix hauts et bas
    1. 3.11.1. Exemple de structure :  script Java
  11. 3.12. Authentification
    1. 3.12.1. Exemple de structure :  script Java
  12. 3.13. Connexion
    1. 3.13.1. Exemple de structure :  script Java
  13. 3.14. Déconnexion
    1. 3.14.1. Exemple de structure :  script Java
  14. Error parsing json

 

Introduction

Le système de négociation parallèle Coinsquare SNP est accessible par abonnement via le protocole FIX (pour Financial Information Exchange) et via Websocket API. Ce document décrit les spécifications pour les trois types de connexion :

  1. Via le protocole FIX, pour les données du marché
  2. Via le protocole FIX, pour le routage des ordres
  3. Websocket API

1. Protocole FIX pour les données du marché

1.1 Clause de non-responsabilité et droits accordés

L’information contenue dans le présent document décrit l’implémentation par Coinsquare Ltd. du protocole FIX, et toute autre information ou documentation relative aux formats des messages pour les spécifications FIX employées par Coinsquare SNP pour les données du marché est fournie « telle quelle », et ni Coinsquare SNP ni aucun de ses affiliés ne font aucune représentation ou garantie, expresse ou implicite, quant au contenu des spécifications FIX employées par Coinsquare SNP pour les données du marché et chacune de ces personnes décline spécifiquement toute garantie d’originalité, d’exactitude, d’exhaustivité, de qualité marchande, de conformité pour un usage particulier, ou qu’il est exempt d’erreurs. En utilisant les spécifications FIX employées par Coinsquare SNP pour les données du marché, vous acceptez d’assumer l’intégralité des risques associés à leur utilisation.

Coinsquare SNP n’assume aucune responsabilité pour les dommages de quelque nature que ce soit en raison de ou en relation avec votre utilisation ou votre incapacité à utiliser les spécifications FIX employées par Coinsquare SNP pour les données du marché, qu’ils soient directs, indirects, accessoires, spéciaux ou consécutifs, sous contrat ou autrement, que Coinsquare SNP ou l’un de ses affiliés ait été ou non informé de la possibilité de tels dommages ou ait autrement anticipé la possibilité de tels dommages.

Veuillez noter que Coinsquare SNP exigera une certification préalable de tout système conçu pour se connecter à ses informations de négociation et de marché ainsi que votre participation de temps à autre dans le cadre des tests de modifications ou de mises à niveau des spécifications FIX employées par Coinsquare SNP pour les données du marché.

Les informations contenues dans les spécifications FIX employées par Coinsquare SNP pour les données du marché sont des informations exclusives et confidentielles appartenant à Coinsquare SNP et Fix Protocol Limited et/ou à leurs concédants de licence ou fournisseurs de services respectifs, selon le cas. Les droits d’auteur et de marque de commerce et toute autre propriété intellectuelle dans les spécifications FIX employées par Coinsquare SNP pour les données du marché appartiennent à Fundamental Interactions, FIX Protocol Limited et/ou ses concédants de licence ou fournisseurs de services, selon le cas. Votre utilisation autorisée des spécifications FIX employées par Coinsquare SNP pour les données du marché, en tout ou en partie, est limitée au droit personnel non exclusif, non transférable, révocable, non cessible pour vous uniquement pour établir une connexion entre vos systèmes et le système de négociation Coinsquare SNP.

Le droit d’auteur des spécifications FIX employées par Coinsquare SNP pour les données du marché appartient à Coinsquare Ltd., 2021. Tous droits réservés.

Le droit d’auteur du protocole FIX appartient à FIX Protocol Limited : </span >www.fixprotocol.org</a ></span >. Le contenu du protocole FIX, les documents, les informations et le matériel s’y rapportant sont utilisés uniquement avec l’autorisation de FIX Protocol Limited.

1.2 Sommaire

Les informations contenues dans ce document décrivent comment adapter le standard FIX 4.2 pour que les fournisseurs et les abonnés puissent communiquer avec le système de négociation parallèle de cotation et d’exécution Coinsquare SNP. Ce document contient des références à plusieurs tags de FIX 4.2 qui sont décrits en détail sur le site du Financial Information Exchange Protocol Committee (</span >www.fixprotocol.org</a ></span >), en plus de tags personnalisés; nous vous suggérons de prendre connaissance des plus récentes modifications à cette version.  

Si le présent document n’inclut pas un message de l’application Financial Information Exchange Protocol version 2 ou, ce message n’est pas pris en compte par MPID.

1.3 Types de données

Les estampilles temporelles (timestamps) FIX sont basées sur le temps universel (Greenwich Mean Time) en accord avec la norme adoptée par FIX. Les clients devraient synchroniser leurs horloges avec une source horaire externe.

Prix – Les clients doivent programmer leurs systèmes pour permettre aux prix d’exécution d’être retournés avec jusqu’à six décimales.

1.4. Symbologie

Les messages FIX entrant dans MPID adoptent la symbologie ci-dessous. Avec le format CMS, le client devrait envoyer le symbole root dans le tag 55. Si le client utilise la symbologie, il devrait tout envoyer dans le tag 55.

 

Catégorie de sécurité

Symbole

Bitcoin en $ CAN

BTCCAD

Ethereum en $ CAN

ETHCAD

1.5. Récupération

MPID offre aux clients une connexion FIX à un site principal et un site secondaire pour obtenir les données en continu. Les deux sites sont synchronisés en temps réel et l’information relative à la session (par exemple le numéro de séquence entrant ou sortant) est conservée sur les deux sites.

Un seul site est actif à la fois. Le site inactif rejettera les tentatives de connexion par socket.

Le processus du client devrait d’abord essayer de se connecter au site principal et en cas d’échec, essayer de se connecter au site secondaire, et ainsi de suite.  

1.6. En-tête et fin de message standard

1.6.1. En-tête de message

 

Tag

Nom du champ

Requis

Commentaires

8

BeginString

O

 « FIX.4.2 »

9

BodyLength

O

(jamais crypté, doit être le deuxième champ du message)

35

MsgType

O

(jamais crypté, doit être le troisième champ du message)

49

SenderCompID

O

Fourni par l’administrateur du système MPID, doit être spécifié dans tous les messages FIX à destination du MPID, sera retourné en écho dans TargetCompID pour tous les messages FIX destinés aux clients

56

TargetCompID

O

Fourni par le client, toujours retourné en écho dans SenderCompID pour tous les messages FIX destinés aux clients

115

OnBehalfOfCompID

N

Requis pour se connecter au Service Bureau

34

MsgSeqNum

O

(peut être intégré dans la section des données cryptées)

43

PossDupFlag

N

Toujours requis pour les messages retransmis, que ce soit à l’invite du système expéditeur ou par suite d’une requête de retour de message (peut être intégré dans la section des données cryptées)

97

PossResend

N

N’est pas pris en compte par MPID

52

SendingTime

O

Requis

122

OrigSendingTime

N

Requis pour les retours de messages; si les données ne sont pas disponibles, prend la même valeur que SendingTime (peut être intégré dans la section des données cryptées)

1.6.2. Fin de message

 

Tag

Nom du champ

Requis

Commentaires

10

CheckSum

O

(jamais crypté, toujours le dernier champ du message)

1.7. Messages relatifs à la session

1.7.1.Heartbeat (MsgType = 0)

Ce message surveille l’état du lien de communication pendant les périodes d’inactivité. La connexion FIX pour les données du marché accepte et génère des messages Heartbeat selon le standard FIX.

  • Entrant : traité tel que spécifié
  • Sortant : en réponse à une requête de test ou à une échéance
  • En réponse : aucun

Le message Heartbeat devrait être envoyé si la durée fixée de Heartbeatinterval s’est écoulée depuis le dernier message envoyé. Si un message a été envoyé pendant le Heartbeatinterval précédent, il n’est pas nécessaire d’envoyer un message Heartbeat.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 0

112

TestReqID

N

Requis quand le message récurrent résulte d’un message de requête de test

 

Standard Trailer

O

 

1.7.2. Logon  (MsgType = A)

Le message de connexion identifie et authentifie l’utilisateur ou le membre et établit une connexion avec la passerelle FIX. La passerelle Fix accepte les messages de connexion sur la base du standard FIX. De plus, la passerelle FIX prend en charge la séquence de connexion pour l’authentification nécessaire à la session. Une fois la connexion établie tel que décrit par le standard, la passerelle FIX :

  1. Lance le traitement de la retransmission via une requête de  retransmission si le numéro de séquence de Logon est plus grand que la valeur attendue.
  2. Lance le traitement de la déconnexion via un message Logout approprié, puis attend une confirmation de Logout avant d’effectuer la déconnexion si le numéro de séquence de Logon est plus petit que la valeur attendue. Si aucune confirmation du Logout n’est reçue après une courte période de temps, la session sera déconnectée.
  3. Gère les requêtes de retransmission.
  4. Lance une connexion avec SenderCompID dans l’en-tête du message.
  5. Achemine au client FIX les messages en attente dans la file d’attente sortante.
  6. Débute la communication du message.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = A

108

HeartBtInt

O

Intervalle entre messages Heatbeat (en secondes)

 

Standard Trailer

O

 

1.7.3. Test Request (MsgType = 1)

Si la valeur de Heartbeatinterval + 1 seconde s’est écoulée depuis le dernier message reçu, une requête de test doit être émise. Si une autre période de Heartbeatinterval + 1 seconde passe sans qu’un message ait été reçu, la connexion TCP devrait se terminer.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 1

112

TestReqID

O

 

 

Standard Trailer

O

 

1.7.4. Resend Request (MsgType = 2)

Ce message lance la retransmission des messages. Le client FIX ou la passerelle peut générer une requête de retransmission quand les numéros de séquence des messages ne se suivent pas. Pour une description complète du traitement des retransmissions, voir la documentation du protocole FIX.

Le système FIX gère les requêtes de retransmission conformément au protocole FIX. Pour les détails sur le traitement des retransmissions, voir les spécifications de FIX 4.2.

Un message Resend Request devrait être traité même s’il est reçu en avance dans la séquence. Un message Resend Request ne devrait être émis dans la direction contraire que lorsque l’étendue de la requête (tous marqués PossDup= “Y”, incluant le remplissage des espaces vides) a été retransmise.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 2

7

BeginSeqNo

O

 

16

EndSeqNo

O

 

 

Standard Trailer

O

 

1.7.5. Reject (Msg Type = 3)

La passerelle FIX utilise ce message pour rejeter les messages qui ne respectent pas les règles de niveaux de la session et qui ne peuvent être traités.  La passerelle examine les messages entrants pour y trouver les tags requis. Elle valide aussi le tag du type de message. Les rejets au niveau de la session sont utilisés pour signaler les violations au protocole pour la session ou les champs manquants.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 3

45

RefSeqNum

O

MsgSeqNum du message rejeté

58

Text

N

Lorsque possible, le message explique la raison du rejet

 

Standard Trailer

O

 

1.7.6. Sequence Reset (MsgType = 4)

Ce message est utilisé pour réinitialiser le numéro de séquence entrant de la direction contraire. Deux modes sont pris en charge :

  1. Sequence Reset-GapFill – GapFillFlag=Y
  2. Sequence Reset-Reset – GapFillFlag=N (Utiliser uniquement pour récupérer après un désastre)

GapFill peut être utilisé pour marquer la place d’un ou de plusieurs messages d’administration ou autres qui ne sont pas retransmis. Pour les détails sur les fonctionnalités du message Sequence Reset (Gap Fill), voir le protocole FIX.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 4

123

GapFillFlag

N

Y=Gap fill commence à NewSeqNo

N=NewSeqNo n’est pas pris en compte  – une récupération manuelle a été tentée

36

NewSeqNo

O

Prochain numéro de séquence demandé

 

Standard Trailer

O

 

1.7.7. Logout (MsgType = 5)

Ce message lance ou confirme la fin d’une session FIX.

La passerelle reçoit et génère les messages de déconnexion tel que requis par le protocole FIX. La passerelle respecte la séquence prescrite des messages pour mettre fin à la session de façon correcte.

Les messages reçus par la passerelle après que le client se soit déconnecté sont stockés dans un fichier de journalisation (log file) pour être transmis au client quand il se connecte à nouveau au cours de la même journée de négociation. Les messages à transmettre dépendent de la réconciliation du numéro de séquence qui se fait lorsque la liaison s’établit (logon handshake).

À la réception d’un message Logout :

  1. La passerelle envoie au client un message de confirmation de la déconnexion.
  2. La session est déconnectée.

La passerelle FIX ne devrait pas lancer une déconnexion, sauf si une erreur majeure survient.

Les deux parties peuvent émettre un Logout pour fermer la session.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 5

58

Text

N

 

 

Standard Trailer

O

 

Remarque : Fermeture de session non requise.

Messages de l’application – Client à MPID

1.7.8. Market Data Request (MsgType = V)

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = V

262

MDReqID

O

Identifiant unique pour une requête de données du marché

Doit être unique ou contenir l’identifiant de la requête précédente à désactiver si SubscriptionRequestType =  Désactiver instantané précédent + Requête de mise à jour (2)

263

SubscriptionRequestType

O

Type de requête d’abonnement

Valeurs valides :

1 = Instantané (snapshot) + Mises à jour

(s’abonner)

2 = Désactiver instantané précédent + Requête de mise à jour

(se désabonner)

264

MarketDepth

O

Profondeur du marché pour l’instantané du registre

La valeur actuelle est ignorée. MPID rapporte le haut du registre dans l’instantané et le registre complet dans les mises à jour

265

MDUpdateType

N

Spécifie le type de mise à jour des données du marché. La valeur actuelle est ignorée. Quand un client s’inscrit, un rafraîchissement incrémentiel est fait.

Valeurs valides :

1 =  rafraîchissement incrémentiel

266

AggregatedBook

N

Détermine si les entrées au registre doivent ou non être agrégées

La valeur actuelle est ignorée. Quand un client s’inscrit, un registre agrégé lui est envoyé

Valeurs valides :

O = une entrée au registre par côté, par prix

267

NoMDEntryTypes

O

Nombre de champs MDEntryType demandés. Les valeurs actuelles sont ignorées. Quand un client s’inscrit, il reçoit l’information sur les cours d’acheteur et de vendeur.

->

269         </span ></span > MDEntryType

O

Type d’entrée de données du marché que le client veut recevoir. La valeur actuelle est ignorée.

146

NoRelatedSym

O

Nombre de symboles demandés

->

55

O

Y

Doit être le premier champ dans le groupe répété

->

65

SymbolSfx

N

 

 

Standard Trailer

O

 

 

1.8. Exemple de message FIX

Une requête pour les données du marché associées à un symbole ressemblerait à

8=FIX.4.29=12435=V49=TESTMD56=TEST34=352=20130819-

19:04:49262=35184372088833263=1264=0265=1266=Y267=2269=0269=1146=155=MSFT10=164

Messages de l’application –MPID à client

Données du marché – Instantané du haut du registre (MsgType=W)

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = W

262

MDReqID

O

MDReqID du message MarketDataRequest

55

Symbol

O

Identifiant du symbole

65

SymbolSfx

N

 

268

NoMDEntries

O

Nombre d’entrées de données du marché dans cet instantané

->

269

MDEntryType

O

Type d’entrée de donnée du marché

Valeurs valides :

  1. = cours d’acheteur (bid)
  2. = cours de vendeur (offer)

->

270

MDEntryPx

O

Prix de l’entrée d’une donnée du marché

->

271

MDEntrySize

N

Quantité de parts représentées par Market Data Entry.

 

Standard Trailer

O

 

 

1.9. Exemple de message FIX

En réponse à une requête valide de données du marché, MPID fournira les meilleurs cours d’acheteur et de vendeur. Le message FIX ressemblerait à

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

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = X

262

MDReqID

O

MDReqID du message MarketDataRequest

268

NoMDEntries

O

Nombre d’entrées de données du marché dans cet instantané

->

279

MDUpdateAction

O

Type de mise à jour des données du marché

Doit être le premier champ dans le groupe répété

Seule valeur valide

0 = Nouvelle

2 = Supprimer

->

269

MDEntryType

O

Type d’entrée de données du marché

Valeurs valides :

  1. = cours d’acheteur (bid)
  2. = cours de vendeur (offer)

->

278

MDEntryID

O

Identifiant des données du marché

->

55

Symbol

O

Identifiant du symbole

->

270

MDEntryPx

O

Prix de l’entrée de données du marché

->

271

MDEntrySize

O

Quantité de parts représentées par l’entrée de données du marché

->

387

TotalVolumeTraded

N

Négociation seulement, quantité de parts négociées pour cette valeur mobilière

 

Standard Trailer

O

 

1.10. Exemple d’un message FIX

En réponse à une requête valide de données du marché, MPID fournira des mises à jour incrémentielles. Le message FIX ressemblerait à

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

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = Y

262

MDReqID

O

MDReqID du message MarketDataRequest

58

Text

N

Raison du rejet

Standard Trailer

O

2. Protocole FIX pour le routage des ordres

2.1. Clause de non-responsabilité et droits accordés

L’information contenue dans le présent document décrit l’implémentation par Coinsquare Ltd. du protocole FIX, et toute autre information ou documentation relative aux formats des messages pour les spécifications FIX employées par Coinsquare SNP pour le routage des ordres est fournie « telle quelle », et ni Coinsquare SNP ni aucun de ses affiliés ne font aucune représentation ou garantie, expresse ou implicite, quant au contenu des spécifications FIX employées par Coinsquare SNP pour le routage des ordres et chacune de ces personnes décline spécifiquement toute garantie d’originalité, d’exactitude, d’exhaustivité, de qualité marchande, de conformité pour un usage particulier, ou qu’il est exempt d’erreurs. En utilisant les spécifications FIX employées par Coinsquare SNP pour le routage des ordres, vous acceptez d’assumer l’intégralité des risques associés à leur utilisation.

Coinsquare SNP n’assume aucune responsabilité pour les dommages de quelque nature que ce soit en raison de ou en relation avec votre utilisation ou votre incapacité à utiliser les spécifications FIX employées par Coinsquare SNP pour le routage des ordres, qu’ils soient directs, indirects, accessoires, spéciaux ou consécutifs, sous contrat ou autrement, que Coinsquare SNP ou l’un de ses affiliés ait été ou non informé de la possibilité de tels dommages ou ait autrement anticipé la possibilité de tels dommages.

Veuillez noter que Coinsquare SNP exigera une certification préalable de tout système conçu pour se connecter à ses informations de négociation et de marché ainsi que votre participation de temps à autre dans le cadre des tests de modifications ou de mises à niveau des spécifications FIX employées par Coinsquare SNP pour le routage des ordres.

Les informations contenues dans les spécifications FIX employées par Coinsquare SNP pour le routage des ordres sont des informations exclusives et confidentielles appartenant à Coinsquare SNP et Fix Protocol Limited et/ou à leurs concédants de licence ou fournisseurs de services respectifs, selon le cas. Les droits d’auteur et de marque de commerce et toute autre propriété intellectuelle dans les spécifications FIX employées par Coinsquare SNP pour le routage des ordres appartiennent à Fundamental Interactions, FIX Protocol Limited et/ou ses concédants de licence ou fournisseurs de services, selon le cas. Votre utilisation autorisée des spécifications FIX employées par Coinsquare SNP pour le routage des ordres, en tout ou en partie, est limitée au droit personnel non exclusif, non transférable, révocable, non cessible pour vous uniquement pour établir une connexion entre vos systèmes et le système de négociation Coinsquare SNP.

Le droit d’auteur des spécifications FIX employées par Coinsquare SNP pour le routage des ordres appartient à Coinsquare Ltd., 2021. Tous droits réservés.

Le droit d’auteur du protocole FIX appartient à FIX Protocol Limited : </span >www.fixprotocol.org</a ></span >. Le contenu du protocole FIX, les documents, les informations et le matériel s’y rapportant sont utilisés uniquement avec l’autorisation de FIX Protocol Limited.

2.2. Sommaire

Les informations contenues dans ce document décrivent comment adapter le standard FIX 4.2 pour que les fournisseurs et les abonnés puissent communiquer avec le système de négociation parallèle de cotation et d’exécution Coinsquare SNP. Ce document contient des références à plusieurs tags de FIX 4.2 qui sont décrits en détail sur le site du Financial Information Exchange Protocol Committee (</span >www.fixprotocol.org</a ></span >), en plus de tags personnalisés; nous vous suggérons de prendre connaissance des plus récentes modifications à cette version. 

Si le présent document n’inclut pas un message de l’application Financial Information Exchange Protocol version 2 ou, ce message n’est pas pris en compte par MPID.

2.3. Types d’ordres pris en charge

Actuellement, Coinsquare SNP prend en charge les types d’ordres à cours limité.

 

Type d’ordre

Description

Ordre limité

Un ordre à cours limité est un ordre pour l’achat ou la vente d’un actif à un cours spécifique ou à un meilleur cours. Pour l’achat, un ordre à prix limité peut seulement être exécuté au prix limité ou moindre. Pour la vente, un ordre à cours limité peut seulement être exécuté au cours limité ou à un cours plus élevé. Un ordre à cours limité ne peut être exécuté que si

le prix de l’actif  atteint le cours limité.

2.4. Symbologie

Pour les messages FIX entrant dans MPID (Market Participant Identity), les clients devraient envoyer le symbole root dans le tag 55.

 

Titre
Paires d’actifs

Exemples de symboles

Bitcoin in CAD

BTCCAD

Ethereum in CAD

ETHCAD

Solana in CAD

SOLCAD

2.5 Se connecter à Coinsquare SNP

2.5.1 Connexion physique

Les connexions sont établies via des connexions directes. Le personnel de  Coinsquare assignera une adresse IP et un numéro de port pour que vous puissiez vous connecter sous le protocole FIX via votre fournisseur de services de communication.

2.5.2. Identification et procédure de connexion

Pour établir la connexion, vous avez besoin de l’adresse IP, du numéro du port et de SenderCompID et TargetCompID.  SenderCompID contient l’identifiant assigné à l’abonné qui est utilisé dans l’en-tête du message au client.  

 

IP Address

Assigné par notre personnel

Validé pendant la connexion initiale

Port

Assigné par notre personnel

Validé pendant la connexion initiale

SenderCompID

Assigné par notre personnel

Validé à la connexion TCP

TargetCompID

Assigné par notre personnel

Validé à la connexion TCP

  1. Le client établit une connexion TCP via son propre moteur FIX ou via un moteur FIX commercial, en utilisant l’adresse IP qui lui a été assignée et le numéro du port.
  2. L’adresse IP et le numéro du port fournis sont examinés et la connexion est établie sur validation de ces informations. Si l’information d’identification ne passe pas l’étape de validation, la connexion est refusée.
  3. Le message de connexion est le premier message que le protocole FIX s’attend à recevoir après que la connexion TCP est établie. (Voir le format du message de connexion dans la section 2.10 ci-dessous.)
  4. Une vérification est faire de SenderCompID et TargetCompID reçus dans l’en-tête du message de connexion; s’il y a validation, la connexion TCP est établie avec la passerelle FIX. Si ces identifiants ne sont pas validés, la connexion est terminée.    
  5. À l’ouverture d’une session, le protocole FIX émet un message de confirmation de connexion.

2.6. Messages FIX

Cette section décrit les messages FIX,  comment ils sont pris en charge et comment la passerelle FIX interprète les données d’affaire.

2.6.1. Messages FIX pris en charge

La passerelle FIX prend en charge les messages suivants :

 

Catégorie

Nom

Type

Direction

Fonction

Administrative

Heartbeat

0

Entrant

Sortant

Fait le suivi de l’état de la passerelle FIX pendant les périodes d’inactivité

Administrative

Logon

A

Entrant

Sortant

Identifie et authentifie un utilisateur/membre qui établit une connexion à la passerelle FIX

Administrative

Test Request

1

Entrant

Sortant

Vérifie la ligne de communication et autres paramètres de la passerelle FIX

Administrative

Resend Request

2

Entrant

Sortant

Lance la retransmission des messages de la passerelle FIX

Administrative

Reject

3

Entrant

Sortant

Rejette les messages qui ne peuvent pas être traités par la passerelle FIX

Administrative

Sequence

Reset (Gap Fill)

4

Entrant

Sortant

Ce message a deux modes :

  • Sequence Reset – Gap Fill pour remplir ou marquer l’écart
  • Sequence Reset – Reset pour forcer la synchronisation

Administrative

Logout

5

Entrant

Sortant

Utilisé pour terminer une session FIX

Customer

New Order – Single

D

Entrant

Sortant

Soumet un ordre d’achat ou de vente à cours limité pour un titre listé dans un marché. Peut contenir des termes comme day, open, good til date.

ATS to Customer

Execution Report

8

Sortant

Don’t Know Trade

Q

Entrant

Rejette un rapport d’exécution traité et envoyé par la passerelle FIX

Customer

Order Cancel Request

F

Entrant

Requête d’annulation d’un ordre

Order Cancel Reject

9

Sortant

Rejette un message pour une requête d’annulation ou de remplacement d’un ordre ou pour une requête d’annulation d’un ordre que la passerelle Fix ne peut pas traiter

Order Status Request

H

Entrant

Requête pour la recherche de détails d’un ordre

Business

Message Reject

J

Sortant

Rejette tout message qui ne peut pas être traité par la passerelle FIX et ne peut pas être rejeté par un autre message.

2.7. Tags FIX personnalisés

Les tags suivants sont ajoutés au protocole FIX 4.2.

 

Tag

Nom du champ

Requis

Commentaires

6750

Account Type

N

CL (Client) NC (Non-Client ou Pro) IN (Inventaire/Principal)

7713

No Self Trade Feature

O

Deux caractères;  empêche la négociaiton avec soi-même

(NM par défaut)

7714

No Self Trade Key

O

Empêche l’ordre d’être négocié contre des ordres dont la valeur de la clé est identique

43211

Execution Venue

N

Identifie où la négociation s’effectue; peut être différent de 43210, par exemple CROX

43212

Execution Contra Broker

N

Tag spécifique à MPID; identifie le courtier de l’autre partie

43214

Liquidity Indicator

N

Indicateur de liquidité :

P (provided) =  liquidité fournie

T (took) = liquidité retirée

43229

FractionBase

O

Si la valeur type de la fraction est 100000000

2.8. En-tête et fin de message FIX standard

Tous les messages FIX ont comme préfixe l’en-tête du message et comme suffixe la fin du message. Ils contiennent l’information permettant d’identifier et d’acheminer les messages. Voyez la description des messages pour connaître les tags requis pour les en-têtes et les fins des messages.

2.8.1. En-tête de message

 

Tag

Nom du champ

Requis

Commentaires

8

BeginString

O

 « FIX.4.2 »

9

BodyLength

O

(jamais crypté, doit être le deuxième champ du message)

35

MsgType

O

(jamais crypté, doit être le troisième champ du message)

49

SenderCompID

O

Fourni par l’administrateur du système MPID, doit être spécifié dans tous les messages FIX à destination du MPID, sera retourné en écho dans TargetCompID pour tous les messages FIX destinés aux clients

56

TargetCompID

O

Fourni par le client, toujours retourné en écho dans SenderCompID pour tous les messages FIX destinés aux clients

115

OnBehalfOfCompID

N

Requis pour se connecter au Service Bureau

34

MsgSeqNum

O

(peut être intégré dans la section des données cryptées)

43

PossDupFlag

N

Toujours requis pour les messages retransmis, que ce soit à l’invite du système expéditeur ou par suite d’une requête de retour de message (peut être intégré dans la section des données cryptées)

97

PossResend

N

N’est pas pris en compte par MPID

52

SendingTime

O

Requis

122

OrigSendingTime

N

Requis pour les retours de messages; si les données ne sont pas disponibles, prend la même valeur que SendingTime (peut être intégré dans la section des données cryptées)

2.8.2. Fin de message

La fin de chaque message doit contenir le tag suivant :

 

Tag

Nom du champ

Requis

Commentaires

10

CheckSum

O

(jamais crypté, toujours le dernier champ du message)

2.9. Sessions Drop Copy

La passerelle FIX offre des sessions Drop Copy qui fournissent des copies des messages d’exécution de rapport ayant été à l’origine envoyés à d’autres sessions FIX par la même entreprise. Ces sessions doivent être configurées par Market Operations et aucune connexion particulière n’est requise. Tous les messages administratifs sont pris en charge dans une session Drop Copy et la retransmission fonctionne de la même manière que pour une session FIX régulière.

Quand un rapport d’exécution est envoyé à un client par une session Drop Copy, le message est indiqué comme étant une copie avec CopyMsgIndicator = Y, et le champ OnBehalfOfCompID qui fournit le CompID de la session FIX à laquelle le message a été initialement envoyé.

Les rapports d’exécution où ExecType = 8 (Rejected) ne seront pas copiés par une session Drop Copy. Le serveur rejettera toute tentative de la part d’un client de soumettre un message d’une application dans une session Drop Copy.

2.10. Messages administratifs

Ces messages sont conçus pour satisfaire les exigences du protocole FIX. Ils ne doivent pas contenir d’information d’affaires et en conséquence sont traités à l’interne dans la passerelle FIX. Tous ces messages sont pris en charge.

 

Message

MsgType

Commentaires

Logon

A

Envoyé après la connexion pour identifier et authentifier le client et pour établir la session FIX  

Heartbeat

0

Envoyé pendant la connexion dans le tag 108 par les serveurs FIX à un intervalle prédéfini

TestRequest

1

Envoyé si aucune donnée n’a été reçue à l’intérieur de l’intervalle HeartBeat

ResendRequest

2

Demande à la partie opposée de retransmettre un message qui aurait pu être manqué

Reject Message

3

Utilisé dans la réponse à un message qui ne peut pas être traité

Sequence Reset

4

Réinitialise le numéro de séquence de la session FIX

Logout

5

Envoyé par le client pour terminer la session FIX et effectuer la déconnexion en bonne et due forme

2.10.1. Heartbeat (MsgType = 0)

Le message Heartbeat devrait être envoyé si la durée fixée de Heartbeatinterval s’est écoulée depuis le dernier message envoyé. Si un message a été envoyé pendant le Heartbeatinterval précédent, il n’est pas nécessaire d’envoyer un message Heartbeat.

2.10.2. Logon  (MsgType = A)

Le message de connexion identifie et authentifie l’utilisateur ou le membre et établit une connexion avec la passerelle FIX. La passerelle Fix accepte les messages de connexion sur la base du standard FIX. De plus, la passerelle FIX prend en charge la séquence de connexion pour l’authentification nécessaire à la session. Une fois la connexion établie tel que décrit par le standard, la passerelle FIX :

  1. Lance le traitement de la retransmission via une requête de  retransmission si le numéro de séquence de Logon est plus grand que la valeur attendue.
  2. Lance le traitement de la déconnexion via un message Logout approprié, puis attend une confirmation de Logout avant d’effectuer la déconnexion si le numéro de séquence de Logon est plus petit que la valeur attendue. Si aucune confirmation du Logout n’est reçue après une courte période de temps, la session sera déconnectée.
  3. Gère les requêtes de retransmission.
  4. Lance une connexion avec SenderCompID dans l’en-tête du message.
  5. Achemine au client FIX les messages en attente dans la file d’attente sortante.
  6. Débute la communication du message.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = A

108

HeartBtInt

O

Intervalle entre messages Heatbeat (en secondes)

 

Standard Trailer

O

 

2.10.3. Test Request (MsgType = 1)

Ce message demande le retour d’un message heartbeat et vérifie la ligne de communication et d’autres paramètres FIX.

Les messages entrants pour des requêtes de test causeront une réponse heartbeat appropriée.  

Si la valeur de Heartbeatinterval + 1 seconde s’est écoulée depuis le dernier message reçu, une requête de test doit être émise. Si une autre période de Heartbeatinterval + 1 seconde passe sans qu’un message ait été reçu, la connexion TCP devrait se terminer.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 1

112

TestReqID

O

 

 

Standard Trailer

O

 

2.10.4. Resend Request (MsgType = 2)

Ce message lance la retransmission des messages. Le client FIX ou la passerelle peut générer une requête de retransmission quand les numéros de séquence des messages ne se suivent pas.

Un message Resend Request devrait être traité même s’il est reçu avant la séquence attendue. Un message Resend Request ne devrait être émis dans la direction contraire que lorsque l’étendue de la requête (tous marqués PossDup= “Y”, incluant le remplissage des espaces vides) a été retransmise.

 

Tag

Field Name

Requis

Commentaires

35

Standard Header

O

MsgType = 2

7

BeginSeqNo

O

Numéro séquentiel du message du premier enregistrement de l’ensemble à être retourné

16

EndSeqNo

O

Numéro séquentiel du message du dernier enregistrement de l’ensemble à être retourné. Si la requête est pour un seul message, BeginSeqNo = EndSeqNo. Si la requête est pour tous les messages qui suivent un message en particulier, EndSeqNo = 0  

2.10.5. Reject (Msg Type = 3)

La passerelle FIX utilise ce message pour rejeter les messages qui ne respectent pas les règles de niveaux de la session et qui ne peuvent être traités.  La passerelle examine les messages entrants pour y trouver les tags requis. Elle valide aussi le tag du type de message. Quand le type du message est absent (message entrant avec tag 35) le message de rejet émet la valeur Unknown dans le tag 58, puisque la passerelle FIX ne connaît pas ce message.

 

Tag

Nom du champ

Requis

Commentaires

35

Standard Header

O

MsgType = 3

45

RefSeqNum

O

MsgSeqNum du message rejeté

58

Text

N

Lorsque possible, le message explique la raison du rejet

2.10.6. Sequence Reset (MsgType = 4)

Ce message est utilisé pour réinitialiser le numéro de séquence entrant de la direction contraire. Deux modes sont pris en charge :

  1. Sequence Reset-GapFill – GapFillFlag=Y
  2. Sequence Reset-Reset – GapFillFlag=N (Utiliser uniquement pour récupérer après un désastre)

GapFill peut être utilisé pour marquer la place d’un ou de plusieurs messages d’administration ou autres qui ne sont pas retransmis. Pour les détails sur les fonctionnalités du message Sequence Reset (Gap Fill), voir le protocole FIX.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 4

123

GapFillFlag

N

Y=Gap fill commence à NewSeqNo

N=NewSeqNo n’est pas pris en compte  – une récupération manuelle a été tentée

36

NewSeqNo

O

Prochain numéro de séquence demandé

 

Standard Trailer

O

 

2.10.7. Logout (MsgType = 5)

Ce message lance ou confirme la fin d’une session FIX.

La passerelle reçoit et génère les messages de déconnexion tel que requis par le protocole FIX. La passerelle respecte la séquence prescrite des messages pour mettre fin à la session de façon correcte.

Les messages reçus par la passerelle après que le client se soit déconnecté sont stockés dans un fichier de journalisation (log file) pour être transmis au client quand il se connecte à nouveau au cours de la même journée de négociation. Les messages à transmettre dépendent de la réconciliation du numéro de séquence qui se fait lorsque la liaison s’établit (logon handshake).

À la réception d’un message Logout :

  1. La passerelle envoie au client un message de confirmation de la déconnexion.
  2. La session est déconnectée.

La passerelle FIX ne devrait pas lancer une déconnexion, sauf si une erreur majeure survient.

 

Tag

Nom du champ

Requis

Commentaires

 

Standard Header

O

MsgType = 5

58

Text

N

Chaîne de caractères en format libre (la longueur maximale de ce champ n’est pas spécifiée)

Si le message Logout a été envoyé par la passerelle FIX, ce champ contient Session closed

 

Standard Trailer

O

 

Remarque : Fermeture de session non requise.

2.11. Messages de l’application – Client        

2.11.1. Nouvel ordre – Single (MsgType = D)

Ce message est utilisé pour soumettre un seul ordre au système de négociation afin qu’il soit traité.

 

Tag

Nom du champ

Requis

Commentaires

35

Standard Header

O

MsgType = D

11

ClOrdID

O

Identifiant unique de l’ordre. Doit être unique à l’intérieur de chaque session, maximum de 32 caractères

1

Account

N

Identifiant optionnel du client, sera repassé dans le rapport d’exécution.

Nom mnémonique du compte déterminé par entente entre le courtier et l’institution.

18

ExecInst

N

Peut contenir plusieurs directives, délimitées par des espaces

G = All or None (AON), tout ou rien

21

HandInst

N

Directives de traitement

1 = Ordre d’exécution automatisé, intervention privée, sans courtier

55

Symbol

O

Symbole du titre. Nom commun pour le titre, en langage humain.

Exemples :

BTCCAD

ETHCAD

DOGECAD

54

Side

O

1 = Acheter

2 = Vendre

38

OrderQty

O

Type de donnée (entier).  Quantité de coins à négocier. Multipliée par la valeur de la fraction de base.  Voir FractionBase, tag 43229

43229  

FractionBase

O

Fraction de OrderQty, cette valeur doit toujours être 100,000,000, par exemple  

OrderQty = 1 suppose 0.00000001

(0.00000001 * 100,000,000 = 1)

40

OrdType

O

2 = Limité

44

Price

N

Conditionnelle, requise pour le type d’ordre

59

TimeInForce

N

1 = GTC (Good Till Cancel), valide jusqu’à annulation

3 = IOC (Immediate-Or-Cancel), immédiatement ou annulation

4 = FOK (Fill or Kill), exécution ou annulation

47

Capacity

N

P = Principal

A = Agence (par défaut)

Si absent, la valeur du compte par défaut sera utilisée

6750

Account Type

CL = Client

NC = Non-Client (Defaut)

IN = Inventaire

7713

NoTradeFeature

O

Fonctionnalité empêchant la négociation avec soi-même (self-trade) dans le but de prévenir les opérations fictives. Détermine le comportement de la fonction avec l’utilisation de NoTradeKey.

NM = – (par défaut)  

2 caractères (sans espace):

1er caractère : N = Annuler le plus récent ordre (l’ordre en cours est annulé)

2e caractère : M = empêche la négociation du courtier avec lui-même (seulement les ordres ayant le même numéro de courtier seront empêchés d’être négociés)

E – Réduire la quantité d’ordres  (ne pas utiliser)

 

7714

NoTradeKey

O

Clé générée par le participant; empêche l’ordre d’être négocié avec des ordres dont la valeur de NoTradeKey est la même.

109

ClientID

No

Identifiant de la firme utilisé dans les transactions par des tiers

Standard Trailer

O

2.11.2. Requête d’annulation d’ordre (MsgType = F)

 

Tag

Nom du champ

Requis

Commentaires

35

Standard Header

O

MsgType = F

41

OrigClOrdID

O

ClOrdID de l’ordre précédent

37

OrderID

N

Identifiant unique de l’ordre le plus récent, tel qu’assigné par le courtier

11

ClOrdID

O

Identifiant unique de la requête d’annulation, tel qu’assigné par l’institution.

1

Account

N

Identifiant optionnel du client

40

OrdType

N

55

Symbol

O

54

Side

N

‘1’ = Acheter

‘2’ = Vendre

38

OrderQty

N

47

58

Text

N

Texte au format libre

Le champ sera ignoré

59

TimeInForce

N

43229

FractionalBase

N

Standard Trailer

O

2.12. Messages de l’application – De Coinsquare SNP au client

2.12.1. Rapport d’exécution  (MsgType 8)

 

Tag

Nom du champ

Requis

Commentaires

35

Standard Header

O

MsgType = 8

37

OrderID

O

Identifiant de l’ordre, assigné par le système

11

ClOrdID

N

Retourné en écho à partir de la requête du client

41

OrigClOrdID

N

Retourné en écho à partir de la requête du client

17

ExecID

O

Assigné par le système : ID d’exécution et ID d’activité  

20

ExecTransType

O

19

ExecRefID

N

Requis pour l’annulation et la correction de messages ExecTransType

150

ExecType

O

39

OrdStatus

O

0=New (nouveau)

1= PartiallyFilled (partiellement exécuté)

2=Filled (exécuté)

3=DoneForDay (terminé pour aujourd’hui)

4=Canceled (annulé)

6=PendingCancel (en attente d’annulation)

7=Stopped (arrêté)

8=Rejected (rejeté)

A=PendingNew (en attente d’un nouvel ordre)

C=Expired (échu)

1

Account

N

Copié à partir de la requête du client

55

Symbol

O

Basé sur l’entrée effectuée par le client

54

Side

O

1 = Acheter

2 = Vendre

38

OrderQty

O

40

OrdType

N

2 = Limite

44

Price

N

Prix, par jeton ou monnaie

59

TimeInForce

N

18

ExecInst

N

Peut contenir plusieurs directives, délimitées par des espaces

47

Capacity

N

Retourné en écho à partir de la requête du client

32

LastQTY

O

Quantité de parts achetées/vendues avec l’écart le plus récent

31

LastPx

O

Prix de ce dernier écart

151

LeavesQty

O

Quantité de parts disponibles pour une exécution  à venir

14

CumQty

O

Parts actuellement exécutées pour la chaîne d’ordres

6

AvgPx

O

Prix moyen calculé de tous les écarts dans cet ordre

6750

Account Type

N

Retourné en écho à partir de la requête du client

43211

Execution Venue

N

Tag particulier à MPID.

Exemple CROX

43212

Execution Contra Broker

N

Tag particulier à MPID

43214

Liquidity Indicator

N

T (Taker), preneur

P (Passive / Maker), faiseur passif

3. Websocket API

3.1 Sommaire

Bienvenue à la documentation sur l’interface de programmation API. Ce document présente les fonctionnalités de négociation de la plateforme, les détails sur le marché ainsi que l’interface API.

Il y a deux catégories d’API :

  • publique, qui fournit les données du marché;
  • privée, qui requiert une authentification et donne accès à la création des ordres et aux autres informations sur le compte.

3.2. Limitation de l’API

Le nombre de connexions permises par l’API est limité afin de prévenir les abus qui risqueraient de diminuer notre capacité à maintenir une performance égale pour tous les utilisateurs.

API WebSocket

    Points de chute publics

Les points de chute publics sont limités pour les adresses IP : 3 requêtes par seconde, un maximum de 6 requêtes en rafale par seconde. La limite pour certains points de chute peut être personnalisée.

    Points de chute privés

Les points de chute privés sont limités pour les identifiants d’utilisateurs : 5 requêtes par seconde, un maximum de 10 requêtes en rafale par seconde. La limite pour certains points de chute peut être personnalisée.

3.3. Format de l’heure

Les champs pour les estampilles temporelles (timestamps) utilisent le format Epoch/POSIX. Sous Unix et POSIX, la mesure du temps est déterminée par le nombre de secondes écoulées depuis le 1 janvier 1970 00:00:00 UTC

N’utilisez pas les millisecondes. ‘1614331055’ ou ‘1614331055000’ sont pris en charge. ‘1614331055123’ n’est pas pris en charge.

3.4. Connectivité

La connexion WebSocket fournit les données sur les ordres et les négociations en temps réel.

wss://ats-production.coinsquare.com:8081

Pour les tests, utilisez

wss://exchange.fi.sandbox.coinsquarex.com:8081/

WebSocket utilise un protocole bidirectionnel qui code tous les messages comme étant des objets JSON. Chaque message possède un attribut de type qui peut être utilisé pour bien gérer les messages.

Veuillez noter que de nouveaux types de messages peuvent être entrés en tout temps. Les clients ne devraient pas tenir compte des messages qui ne sont pas pris en charge.

Si une première connexion échoue, assurez-vous d’ajouter les certificats requis; suivez les étapes décrites dans l’article </span >Adding the required SSL certificates</a ></span >.

3.4.1. Exemple de structure :  script Java

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. Données sur le marché

3.5.1. Point de chute getsymbols

Catégorie : Données sur le marché

Permissions : Public

Point de chute : getsymbols

Récupère de la plateforme les actifs courants et les paires négociées.

Réponse

 

Clé

Valeur

security

chaîne de caractères         

Paire négociée ou actif

fractionbase

chaîne de caractères

Nombre de décimales prises en charge, par exemple 100 = 1.00

tradingsymbol

chaîne de caractères

Vrai = paire négociée
Faux = actif

pair_first

chaîne de caractères

Indique le premier actif, par exemple LTC ou CAD

fiat

chaîne de caractères

Vrai = fiat
Faux = actif numérique

pair

chaîne de caractères

Vrai = paire négociée
Faux = actif

3.5.2. Exemple de structure :  script Java

# 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. Point de chute subscribe (registre des ordres)

Catégorie : Données sur le marché

Permissions : Public

Point de chute : subscribe

Récupère l’information sur le plus récent registre, puis abonne l’utilisateur aux mises à jour continues des événements relatifs aux données de marché sur les paires négociées spécifiées.

Les réponses de l’appel Subscribe sont données ci-dessous. Les messages sont ensuite envoyés périodiquement dans le format de l’information UpdateEvent quand il y a un changement dans le meilleur cours d’achat et/ou le meilleur cours de vente. Ceci se produit jusqu’à ce que vous fermiez la connexion.

Requête

 

Clé

Valeur

Requis

msg

chaîne de caractères         

Type de donnée pour laquelle créer un abonnement.

Utiliser « book » pour les données sur le registre des ordres

oui

security

chaîne de caractères

Paire négociée pour laquelle créer un abonnement

oui

dest

chaîne de caractères

Cette valeur est toujours CROX.

oui

Réponse

 

Clé

Valeur

security

chaîne de caractères         

Paire négociée faisant l’objet de l’abonnement

side

chaîne de caractères

L’autre côté

act

chaîne de caractères

Action de mettre à jour ou de retirer des ordres

price

chaîne de caractères

Prix de l’ordre

qty

chaîne de caractères

Taille de l’ordre

time

chaîne de caractères

Heure de l’ordre au format POSIX

Pour identifier plusieurs paires négociées (valeurs mobilières) utilisez l’astérisque (*).

3.6.1. Exemple de structure :  script Java

# 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. Point de chute subscribe (négociation en direct)

Catégorie : Négociations en direct

Permissions : Public

Point de chute : subscribe

Récupère la plus récente information sur la négociation, puis abonne l’utilisateur  aux mises à jour continues des événements relatifs aux données de marché sur les paires négociées spécifiées.

Les réponses de l’appel Subscribe sont données ci-dessous. Les messages sont ensuite envoyés périodiquement dans le même format que la réponse jusqu’à ce que vous fermiez la connexion.

Requête

 

Clé

Valeur

Requis

msg

chaîne de caractères         

Type de donnée pour laquelle créer un abonnement; utiliser « trade » pour les données de l’historique de négociation

oui

security

chaîne de caractères

Paire négociée pour laquelle créer un abonnement

oui

dest

chaîne de caractères

Cette valeur est toujours CROX

oui

Réponse

 

Clé

Valeur

security

chaîne de caractères         

Paire négociée faisant l’objet de l’abonnement

src

chaîne de caractères

Cette valeur est toujours CROX

price

chaîne de caractères

Prix de l’ordre

qty

chaîne de caractères

Taille de l’ordre

time

chaîne de caractères

Heure de l’ordre au format POSIX

type

chaîne de caractères

Type d’enregistrement

Matched

chaîne de caractères

ID de référence de l’échange pour la négociation

Pour une négociation en direct, vous devez spécifier une seule paire négociée.

3.7.1. Exemple de structure :  script Java

# 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. Requête de l’historique de négociation

Catégorie : Historique de négociation

Permissions : Public

Point de chute : lshistory

La requête retourne les données sur l’historique de négociation à partir de l’heure de début spécifiée. Le nombre d’enregistrements que vous devriez avoir est indiqué par total_rec et le nombre d’enregistrements que vous avez est indiqué par rec_no.

Requête

 

Clé

Valeur

Requis

type

chaîne de caractères         

Type de données auquel s’abonner en utilisant  tradehistory pour les données de l’historique

oui

security

chaîne de caractères

Paire négociée à laquelle vous abonner        

oui

starttime

chaîne de caractères

Heure de début au format POSIX

oui

Réponse

 

Clé

Valeur

security

chaîne de caractères         

Paire négociée faisant l’objet de l’abonnement

execprice

chaîne de caractères

Prix de l’ordre

execqty

chaîne de caractères

Taille de l’ordre

time

chaîne de caractères

Heure de l’ordre au format POSIX

rec_no

entier

Heure du début de la fenêtre

starttime

chaîne de caractères

Type d’enregistrement

total_rec

chaîne de caractères

Quantité d’enregistrements affichés

Pour l’historique d’exécution, vous devez spécifier une seule paire négociée.

3.8.1. Exemple de structure :  script Java

# 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. Requête de l’historique de négociation complet

Catégorie : Historique de négociation

Permissions : Public

Point de chute : tradehistory

La requête retourne l’historique de négociation dans un bloc de 1 minute. Si une négociation a lieu dans cette minute, un bloc correspondant est retourné avec le sommaire du prix haut/bas/final ainsi que l’information sur le volume et la négociation.

Il peut y avoir plusieurs réponses à une requête si la réponse comporte plus de 100 entrées. Chaque réponse a un maximum de 100 entrées. Le nombre d’enregistrements que vous devriez avoir est indiqué par  total_rec et le nombre d’enregistrements que vous avez est indiqué par rec_no.

Requête

 

Clé

Valeur

Requis

type

chaîne de caractères         

Type de données auquel s’abonner en utilisant  tradehistory pour les données de l’historique

oui

security

chaîne de caractères

Paire négociée à laquelle vous abonner        

oui

Réponse

 

Clé

Valeur

security

chaîne de caractères         

Paire négociée faisant l’objet de l’abonnement

price

chaîne de caractères

Ptrix de l’ordre

qty

chaîne de caractères

Taille de l’ordre

time

chaîne de caractères

Heure de l’ordre au format POSIX

numoftrades

chaîne de caractères

Nombre de négociations

lastttime

chaîne de caractères

Heure de la dernière transaction

blocktime

chaîne de caractères

high price

chaîne de caractères

Prix le plus haut dans la fenêtre

lowprice

chaîne de caractères

Prix le plus bas dans la fenêtre

rec_no

entier

Heure du début de la fenêtre

starttime

chaîne de caractères

Type d’enregistrement

lastprice

chaîne de caractères

Dernier prix de la fenêtre

startprice

chaîne de caractères

Prix de départ de la fenêtre

total_rec

chaîne de caractères

Quantité d’enregistrements affichés

Pour l’historique d’exécution, vous devez spécifier une seule paire négociée.

3.9.1. Exemple de structure :  script Java

# 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. Abonnement à l’état d’une paire négociée

Catégorie : État de la paire négociée

Permissions : Public

Point de chute : subscribesymbolstatus

Récupère les changements de l’état de la paire négociée. Les valeurs possibles sont Halt, PreOpening ou Normal.

Les réponses de l’appel subscribesymbolstatus sont données ci-dessous. Les messages sont envoyés lorsque l’état est modifié.

Requête

 

Clé

Valeur

Requis

type

chaîne de caractères         

Type de données auquel s’abonner en utilisant  subscribesymbolstatus comme symbole

oui

Réponse

 

Clé

Valeur

security

chaîne de caractères         

Type de données auquel s’abonner

time

Heure de l’ordre au format POSIX

status

Nouvel état de la paire négociée

3.10.1 Exemple de structure :  script Java

# 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. Abonnement pour les prix hauts et bas

Catégorie : Données sur le marché

Permissions : Public

Point de chute : subscribehighlow

Abonne l’utilisateur aux mises à jour continues des événements relatifs aux données de marché sur les paires négociées spécifiées quand il y a un nouveau prix haut ou bas pour cette paire. La fenêtre de temps est de 01h00 à 00h59 +1 UTC.

Les réponses de l’appel subscribehighlow sont données ci-dessous. Les messages sont ensuite envoyés périodiquement s’il y a un nouveau prix haut ou bas.

Requête

 

Clé

Valeur

Requis

security

chaîne de caractères         

Paire négociée à laquelle vous voulez vous abonner

oui

Réponse

 

Clé

Valeur

security

chaîne de caractères         

Type de données auquel s’abonner

openingprice

chaîne de caractères

Prix à 01h00 ou prix après le calcul du prix à l’ouverture

highprice

chaîne de caractères

Plus haut prix d’exécution

lowprice

chaîne de caractères

Plus bas prix d’exécution

prevcloseprice

chaîne de caractères

Prix d’exécution à 01h00

Pour identifier plusieurs paires négociées (valeurs mobilières) utilisez l’astérisque (*).

3.11.1. Exemple de structure :  script Java

# 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. Authentification

Catégorie : Authentification

Permissions : Négociation

Une fois que le client a établi la connexion WebSocket, il dispose de 30 secondes pour terminer le processus, autrement Coinsquare ferme le socket.

Défi (challenge)

Le client doit d’abord envoyer une requête de défi au système.

Réponse

 

Clé

Valeur

Key

chaîne de caractères         

Chaîne de caractères utilisée pour chiffrer le mot de passe

Dans la réponse se trouve le champ key qui contient une clé publique en chaîne de caractères que le client doit utiliser pour chiffrer le champ du mot de passe. Le champ key est la reproduction ASCII en base 64 du tableau binaire d’octets pour la clé publique dans la paire de clés asymétriques (publique/privée) correspondante. Coinsquare conserve la clé privée et envoie la clé publique au client. Le client reconvertit la valeur ASCII  en tableau binaire d’octets qu’il utilise pour créer une instance de clé publique RSA. Par la suite, le client utilise l’instance de la clé publique RSA pour chiffrer l’information requise pour son API d’entrée d’ordre, soit le chiffrement du mot de passe.  

Si vous utilisez JavaScript, vous devez utiliser le paquet npm pour installer la bibliothèque jsencrypt.

3.12.1. Exemple de structure :  script Java

# 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.      Connexion

Une fois que le mot de passe est chiffré, la prochaine étape est d’envoyer la requête de connexion. La chaîne de caractères dans le champ pass provient du résultat du script dans l’exemple précédent.

Requête

 

Clé

Valeur

Requis

userid

chaîne de caractères         

Username de l’utilisateur

oui

pass

chaîne de caractères         

Phrase de passe générée à partir du défi (challenge) et des étapes ci-dessus

oui

Réponse

 

Clé

Valeur

result

chaîne de caractères

Si une réponse a été obtenue OK sera affiché, autrement une raison pour le rejet sera affichée.

À la connexion, Coinsquare SNP envoie les ordres ouverts courants et l’information sur les positions. Si un utilisateur envoie un nouvel ordre, Coinsquare SNP envoie automatiquement une mise à jour de l’ordre. Si l’utilisateur effectue l’échange, il recevra une mise à jour de l’échange et des positions correspondantes.

3.12.1. Exemple de structure :  script Java

# 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. Déconnexion

Ceci effectue une déconnexion en bonne et due forme. À la réception de ce message, Coinsquare ferme immédiatement la connexion WebSocket.

3.14.1. Exemple de structure :  script Java

# Request

   {

      “type”:”logout”,

   }

# Response

   {

      “result”:”OK”,

      “type”:”logout”

   }

Error parsing json

Ce message d’erreur indique que votre requête contient des erreurs typographiques.

Exemple

{“result”:”error parsing json”}

https://d33wubrfki0l68.cloudfront.net/9c6282ad47728686af5e3c9dacaa8fb19a8ed32e/e75ee/static/696015a52a9b7e368847be3ae56d0687/company-logo-black.svg
Produit
SNP
Documents juridiques et réglementaires
Tarifs
Accord de Compte Client
Politique de confidentialité
Services
Statut de Coinsquare
Plan du site
Société
Contactez-nous
Aide
Qui sommes-nous?
Blogue
Carrières
Statut réglementaire
Politique de cookies
Comment acheter Bitcoin
Comment acheter Ethereum
Like Coinsquare on FacebookFollow Coinsquare on TwitterFollow Coinsquare on InstagramConnect with Coinsquare on LinkedInFollow Coinsquare on Reddit
© Coinsquare 2022

Les biens, tels que prescrits dans la politique de garantie du Fonds canadien de protection des épargnants (FCPE), qui sont détenus dans les comptes des clients, y compris les soldes en espèces, mais pas les actifs cryptographiques, sont protégés par le FCPE dans les limites spécifiées. Une brochure décrivant la nature et les limites de la garantie est disponible sur demande ou sur le site https://www.fcpe.ca/fr.

FINTRAC Registered