Spécification de connectivité SNP
Comment se connecter à SNP
- 1. Protocole FIX pour les données du marché
- 1.1. Disclaimer and Rights Granted
- 1.1 Clause de non-responsabilité et droits accordés
- 1.2 Sommaire
- 1.3 Types de données
- 1.4. Symbologie
- 1.5. Récupération
- 1.6. En-tête et fin de message standard
- 1.7. Messages relatifs à la session
- 1.8. Exemple de message FIX
- 1.9. Exemple de message FIX
- 1.10. Exemple d’un message FIX
- 2. Protocole FIX pour le routage des ordres
- 2.1. Clause de non-responsabilité et droits accordés
- 2.2. Sommaire
- 2.3. Types d’ordres pris en charge
- 2.4. Symbologie
- 2.5 Se connecter à Coinsquare SNP
- 2.6. Messages FIX
- 2.7. Tags FIX personnalisés
- 2.8. En-tête et fin de message FIX standard
- 2.9. Sessions Drop Copy
- 2.10. Messages administratifs
- 2.11. Messages de l’application – Client
- 2.12. Messages de l’application – De Coinsquare SNP au client
- 3. Websocket API
- 3.5. Données sur le marché
- 3.6. Point de chute subscribe (registre des ordres)
- 3.7. Point de chute subscribe (négociation en direct)
- 3.8. Requête de l’historique de négociation
- 3.9. Requête de l’historique de négociation complet
- 3.10. Abonnement à l’état d’une paire négociée
- 3.11. Abonnement pour les prix hauts et bas
- 3.12. Authentification
- 3.13. Connexion
- 3.14. Déconnexion
- 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 :
- Via le protocole FIX, pour les données du marché
- Via le protocole FIX, pour le routage des ordres
- 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 :
- 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.
- 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.
- Gère les requêtes de retransmission.
- Lance une connexion avec SenderCompID dans l’en-tête du message.
- Achemine au client FIX les messages en attente dans la file d’attente sortante.
- 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 :
- Sequence Reset-GapFill – GapFillFlag=Y
- 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 :
- La passerelle envoie au client un message de confirmation de la déconnexion.
- 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 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 :
|
-> |
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 :
|
-> |
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 |
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 |
- 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.
- 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.
- 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.)
- 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.
- À 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 :
|
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 :
- 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.
- 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.
- Gère les requêtes de retransmission.
- Lance une connexion avec SenderCompID dans l’en-tête du message.
- Achemine au client FIX les messages en attente dans la file d’attente sortante.
- 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 :
- Sequence Reset-GapFill – GapFillFlag=Y
- 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 :
- La passerelle envoie au client un message de confirmation de la déconnexion.
- 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 |
pair_first |
chaîne de caractères |
Indique le premier actif, par exemple LTC ou CAD |
fiat |
chaîne de caractères |
Vrai = fiat |
pair |
chaîne de caractères |
Vrai = paire négociée |
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”}
Dernière mise à jour: 12 octobre 2022