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.

 

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

 

1.6.2. Fin de 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.

 

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.

 

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.

 

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.

 

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.

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.

 

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.

 

Remarque : Fermeture de session non requise.

Messages de l’application – Client à MPID

1.7.8. Market Data Request (MsgType = V)

 

 

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)

 

 

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)

 

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)

 

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

 

2.4. Symbologie

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

 

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.  

 

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 :

 

2.7. Tags FIX personnalisés

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

 

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

 

2.8.2. Fin de message

La fin de chaque message doit contenir le tag suivant :

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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

 

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

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

 

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.

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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

 

 

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.

 

 

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.

 

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.

 

 

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