Spécification de connectivité SNP

Comment se connecter à SNP

1. Protocole FIX pour les données du marché
2. Protocole FIX pour le routage des ordres
3. Websocket API
3.5. Données sur le marché
1. 3.5.1. Point de chute getsymbols
2. 3.5.2. Exemple de structure : script Java
3.6. Point de chute subscribe (registre des ordres)
1. 3.6.1. Exemple de structure : script Java
3.7. Point de chute subscribe (négociation en direct)
1. 3.7.1. Exemple de structure : script Java
3.8. Requête de l’historique de négociation
1. 3.8.1. Exemple de structure : script Java
3.9. Requête de l’historique de négociation complet
1. 3.9.1. Exemple de structure : script Java
3.10. Abonnement à l’état d’une paire négociée
1. 3.10.1 Exemple de structure : script Java
3.11. Abonnement pour les prix hauts et bas
1. 3.11.1. Exemple de structure : script Java
3.12. Authentification
1. 3.12.1. Exemple de structure : script Java
3.13. Connexion
1. 3.13.1. Exemple de structure : script Java
3.14. Déconnexion
1. 3.14.1. Exemple de structure : script Java
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 du protocole FIX appartient à FIX Protocol Limited : www.fixprotocol.org</a >. 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 (www.fixprotocol.org</a >), 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 </span ></span > MDEntryType		O	Type d’entrée de données du marché que le client veut recevoir. La valeur actuelle est ignorée.
146	NoRelatedSym		O	Nombre de symboles demandés
->	55	O	Y	Doit être le premier champ dans le groupe répété
->	65	SymbolSfx	N
	Standard Trailer		O

1.8. Exemple de message FIX

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

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

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

Messages de l’application –MPID à client

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

Tag	Nom du champ		Requis	Commentaires
	Standard Header		O	MsgType = W
262	MDReqID		O	MDReqID du message MarketDataRequest
55	Symbol		O	Identifiant du symbole
65	SymbolSfx		N
268	NoMDEntries		O	Nombre d’entrées de données du marché dans cet instantané
->	269	MDEntryType	O	Type d’entrée de donnée du marché Valeurs valides : = cours d’acheteur (bid) = cours de vendeur (offer)
->	270	MDEntryPx	O	Prix de l’entrée d’une donnée du marché
->	271	MDEntrySize	N	Quantité de parts représentées par Market Data Entry.
	Standard Trailer		O

1.9. Exemple de message FIX

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

8=FIX.4.29=13035=W49=TEST56=TESTMD34=352=20130819-

19:04:4955=MSFT268=2269=0270=30.01271=100269=1270=30.99271=100262=3518437208883310=18

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 : = cours d’acheteur (bid) = cours de vendeur (offer)
->	278	MDEntryID	O	Identifiant des données du marché
->	55	Symbol	O	Identifiant du symbole
->	270	MDEntryPx	O	Prix de l’entrée de données du marché
->	271	MDEntrySize	O	Quantité de parts représentées par l’entrée de données du marché
->	387	TotalVolumeTraded	N	Négociation seulement, quantité de parts négociées pour cette valeur mobilière
	Standard Trailer		O

1.10. Exemple d’un message FIX

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

8=FIX.4.29=13635=X49=TEST56=TESTMD34=552=20130819-

19:05:40262=35184372088833268=1279=0269=0278=108086391056891905155=MSFT270=30.02271=5 0010=059

8=FIX.4.29=13435=X49=TEST56=TESTMD34=752=20130819-

19:05:57262=35184372088833268=1279=2269=0278=108086391056891905155=MSFT270=30.02271=0 10=224

Market Data Request Reject (MsgType=Y)

Tag	Nom du champ	Requis	Commentaires
	Standard Header	O	MsgType = Y
262	MDReqID	O	MDReqID du message MarketDataRequest
58	Text	N	Raison du rejet
	Standard Trailer	O

2. Protocole FIX pour le routage des ordres

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

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

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

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.

2.2. Sommaire

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

2.3. Types d’ordres pris en charge

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

Type d’ordre

Description

Ordre limité

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

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

2.4. Symbologie

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

Titre Paires d’actifs	Exemples de symboles
Bitcoin in CAD	BTCCAD
Ethereum in CAD	ETHCAD
Solana in CAD	SOLCAD

2.5 Se connecter à Coinsquare SNP

2.5.1 Connexion physique

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

2.5.2. Identification et procédure de connexion

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

IP Address	Assigné par notre personnel	Validé pendant la connexion initiale
Port	Assigné par notre personnel	Validé pendant la connexion initiale
SenderCompID	Assigné par notre personnel	Validé à la connexion TCP
TargetCompID	Assigné par notre personnel	Validé à la connexion TCP

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 : Sequence Reset – Gap Fill pour remplir ou marquer l’écart Sequence Reset – Reset pour forcer la synchronisation
Administrative	Logout	5	Entrant Sortant	Utilisé pour terminer une session FIX
Customer	New Order – Single	D	Entrant Sortant	Soumet un ordre d’achat ou de vente à cours limité pour un titre listé dans un marché. Peut contenir des termes comme day, open, good til date.
ATS to Customer	Execution Report	8	Sortant
	Don’t Know Trade	Q	Entrant	Rejette un rapport d’exécution traité et envoyé par la passerelle FIX
Customer	Order Cancel Request	F	Entrant	Requête d’annulation d’un ordre
	Order Cancel Reject	9	Sortant	Rejette un message pour une requête d’annulation ou de remplacement d’un ordre ou pour une requête d’annulation d’un ordre que la passerelle Fix ne peut pas traiter
	Order Status Request	H	Entrant	Requête pour la recherche de détails d’un ordre
	Business Message Reject	J	Sortant	Rejette tout message qui ne peut pas être traité par la passerelle FIX et ne peut pas être rejeté par un autre message.

2.7. Tags FIX personnalisés

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

Tag	Nom du champ	Requis	Commentaires
6750	Account Type	N	CL (Client) NC (Non-Client ou Pro) IN (Inventaire/Principal)
7713	No Self Trade Feature	O	Deux caractères; empêche la négociaiton avec soi-même (NM par défaut)
7714	No Self Trade Key	O	Empêche l’ordre d’être négocié contre des ordres dont la valeur de la clé est identique
43211	Execution Venue	N	Identifie où la négociation s’effectue; peut être différent de 43210, par exemple CROX
43212	Execution Contra Broker	N	Tag spécifique à MPID; identifie le courtier de l’autre partie
43214	Liquidity Indicator	N	Indicateur de liquidité : P (provided) = liquidité fournie T (took) = liquidité retirée
43229	FractionBase	O	Si la valeur type de la fraction est 100000000

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

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

2.8.1. En-tête de message

Tag	Nom du champ	Requis	Commentaires
8	BeginString	O	« FIX.4.2 »
9	BodyLength	O	(jamais crypté, doit être le deuxième champ du message)
35	MsgType	O	(jamais crypté, doit être le troisième champ du message)
49	SenderCompID	O	Fourni par l’administrateur du système MPID, doit être spécifié dans tous les messages FIX à destination du MPID, sera retourné en écho dans TargetCompID pour tous les messages FIX destinés aux clients
56	TargetCompID	O	Fourni par le client, toujours retourné en écho dans SenderCompID pour tous les messages FIX destinés aux clients
115	OnBehalfOfCompID	N	Requis pour se connecter au Service Bureau
34	MsgSeqNum	O	(peut être intégré dans la section des données cryptées)
43	PossDupFlag	N	Toujours requis pour les messages retransmis, que ce soit à l’invite du système expéditeur ou par suite d’une requête de retour de message (peut être intégré dans la section des données cryptées)
97	PossResend	N	N’est pas pris en compte par MPID
52	SendingTime	O	Requis
122	OrigSendingTime	N	Requis pour les retours de messages; si les données ne sont pas disponibles, prend la même valeur que SendingTime (peut être intégré dans la section des données cryptées)

2.8.2. Fin de message

La fin de chaque message doit contenir le tag suivant :

Tag	Nom du champ	Requis	Commentaires
10	CheckSum	O	(jamais crypté, toujours le dernier champ du message)

2.9. Sessions Drop Copy

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

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

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

2.10. Messages administratifs

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

Message	MsgType	Commentaires
Logon	A	Envoyé après la connexion pour identifier et authentifier le client et pour établir la session FIX
Heartbeat	0	Envoyé pendant la connexion dans le tag 108 par les serveurs FIX à un intervalle prédéfini
TestRequest	1	Envoyé si aucune donnée n’a été reçue à l’intérieur de l’intervalle HeartBeat
ResendRequest	2	Demande à la partie opposée de retransmettre un message qui aurait pu être manqué
Reject Message	3	Utilisé dans la réponse à un message qui ne peut pas être traité
Sequence Reset	4	Réinitialise le numéro de séquence de la session FIX
Logout	5	Envoyé par le client pour terminer la session FIX et effectuer la déconnexion en bonne et due forme

2.10.1. Heartbeat (MsgType = 0)

2.10.2. Logon (MsgType = A)

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.

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)

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 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 Adding the required SSL certificates</a >.

3.4.1. Exemple de structure : script Java

const WebSocket = require(‘ws’);

process.env[‘NODE_TLS_REJECT_UNAUTHORIZED’] = 0

const ws = new WebSocket(“wss://ws-sandbox.CoinSquare.com:8081/”)

ws.onopen = function() {

ws.send(JSON.stringify(

{

“type”: “TYPE”,

“request”: “REQUEST”

}

))

ws.onmessage = function(response) {

let websocket_response = JSON.parse(response.data);

console.log(websocket_response)

}

ws.close()

}

3.5. Données sur le marché

3.5.1. Point de chute getsymbols

Catégorie : Données sur le marché

Permissions : Public

Point de chute : getsymbols

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

Réponse

Clé	Valeur
security	chaîne de caractères	Paire négociée ou actif
fractionbase	chaîne de caractères	Nombre de décimales prises en charge, par exemple 100 = 1.00
tradingsymbol	chaîne de caractères	Vrai = paire négociée Faux = actif
pair_first	chaîne de caractères	Indique le premier actif, par exemple LTC ou CAD
fiat	chaîne de caractères	Vrai = fiat Faux = actif numérique
pair	chaîne de caractères	Vrai = paire négociée Faux = actif

3.5.2. Exemple de structure : script Java

# Request

{

“type”: “getsymbols”

}

# Response

{

“result”:”OK”,

“data”:[

{

“security”:”CAD”,

“fractionbase”:100,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”LTCCAD”,

“fractionbase”:10000,

“pair_first”:”LTC”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”LTC”,

“fractionbase”:10000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”ETHCAD”,

“fractionbase”:100000,

“pair_first”:”ETH”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”ETH”,

“fractionbase”:100000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”BTCCAD”,

“fractionbase”:100000,

“pair_first”:”BTC”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”BTC”,

“fractionbase”:100000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

{

“security”:”BCHCAD”,

“fractionbase”:100000,

“pair_first”:”BCH”,

“tradingsymbol”:true,

“fiat”:false,

“pair_second”:”CAD”,

“pair”:true

{

“security”:”BCH”,

“fractionbase”:100000,

“tradingsymbol”:false,

“fiat”:false,

“pair”:false

}

“type”:”getsymbols”

}

3.6. Point de chute subscribe (registre des ordres)

Catégorie : Données sur le marché

Permissions : Public

Point de chute : subscribe

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

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

Requête

Clé	Valeur		Requis
msg	chaîne de caractères	Type de donnée pour laquelle créer un abonnement. Utiliser « book » pour les données sur le registre des ordres	oui
security	chaîne de caractères	Paire négociée pour laquelle créer un abonnement	oui
dest	chaîne de caractères	Cette valeur est toujours CROX.	oui

Réponse

Clé	Valeur
security	chaîne de caractères	Paire négociée faisant l’objet de l’abonnement
side	chaîne de caractères	L’autre côté
act	chaîne de caractères	Action de mettre à jour ou de retirer des ordres
price	chaîne de caractères	Prix de l’ordre
qty	chaîne de caractères	Taille de l’ordre
time	chaîne de caractères	Heure de l’ordre au format POSIX

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

3.6.1. Exemple de structure : script Java

# Request

{

“type”: “subscribe”,

“request”: [

{

“msg”:”book”,

“security”:”BCHCAD”,

“dest”:”CROX”

}

]

}

# Response

# order added

{

“security”:”BCHCAD”,

“books”:[

{

“side”:”B”,

“act”:”U”,

“src”:”CROX”,

“price”:”472.33″,

“qty”:”0.46″,

“id”:120947223715360,

“time”:”1626338416747″,

“mpid”:”ANON”,

“key”:”NA”

}

“type”:”book”

}

# order removed

{

“security”:”BCHCAD”,

“books”:[

{

“act”:”R”,

“id”:120947223715360,

“time”:”1626338444101″

}

“type”:”book”

}

3.7. Point de chute subscribe (négociation en direct)

Catégorie : Négociations en direct

Permissions : Public

Point de chute : subscribe

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

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

Requête

Clé	Valeur		Requis
msg	chaîne de caractères	Type de donnée pour laquelle créer un abonnement; utiliser « trade » pour les données de l’historique de négociation	oui
security	chaîne de caractères	Paire négociée pour laquelle créer un abonnement	oui
dest	chaîne de caractères	Cette valeur est toujours CROX	oui

Réponse

Clé	Valeur
security	chaîne de caractères	Paire négociée faisant l’objet de l’abonnement
src	chaîne de caractères	Cette valeur est toujours CROX
price	chaîne de caractères	Prix de l’ordre
qty	chaîne de caractères	Taille de l’ordre
time	chaîne de caractères	Heure de l’ordre au format POSIX
type	chaîne de caractères	Type d’enregistrement
Matched	chaîne de caractères	ID de référence de l’échange pour la négociation

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

3.7.1. Exemple de structure : script Java

# Request

{

“type”: “subscribe”,

“request”: [

{

“msg”:”trade”,

“security”:”BCHCAD”,

“dest”:”CROX”

}

]

}

# Response

{

“security”:”BCHCAD”,

“src”:”CROX”,

“price”:”471.43″,

“qty”:”0.06969″,

“time”:”1626338546538″,

“type”:”trade”,

“matchid”:”62YNMDOQ2SPR”

}

3.8. Requête de l’historique de négociation

Catégorie : Historique de négociation

Permissions : Public

Point de chute : lshistory

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

Requête

Clé	Valeur		Requis
type	chaîne de caractères	Type de données auquel s’abonner en utilisant tradehistory pour les données de l’historique	oui
security	chaîne de caractères	Paire négociée à laquelle vous abonner	oui
starttime	chaîne de caractères	Heure de début au format POSIX	oui

Réponse

Clé	Valeur
security	chaîne de caractères	Paire négociée faisant l’objet de l’abonnement
execprice	chaîne de caractères	Prix de l’ordre
execqty	chaîne de caractères	Taille de l’ordre
time	chaîne de caractères	Heure de l’ordre au format POSIX
rec_no	entier	Heure du début de la fenêtre
starttime	chaîne de caractères	Type d’enregistrement
total_rec	chaîne de caractères	Quantité d’enregistrements affichés

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

3.8.1. Exemple de structure : script Java

# Request

{

“type”:”lshistory”,

“security”:”ETHCAD”,

“starttime”:”1630530000000″

}

# Response

{

“result”: “OK”,

“security”: “LTCCAD”,

“data”:

[

{

“security”: “LTCCAD”,

“rec_no”: 1,

“execprice”: “182.51”,

“time”: “1630561535942”,

“execqty”: “0.5702”

}

“total_rec”: “1”,

“starttime”: “1630530000000”,

“type”: “lshistory”

}

3.9. Requête de l’historique de négociation complet

Catégorie : Historique de négociation

Permissions : Public

Point de chute : tradehistory

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

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

Requête

Clé	Valeur		Requis
type	chaîne de caractères	Type de données auquel s’abonner en utilisant tradehistory pour les données de l’historique	oui
security	chaîne de caractères	Paire négociée à laquelle vous abonner	oui

Réponse

Clé	Valeur
security	chaîne de caractères	Paire négociée faisant l’objet de l’abonnement
price	chaîne de caractères	Ptrix de l’ordre
qty	chaîne de caractères	Taille de l’ordre
time	chaîne de caractères	Heure de l’ordre au format POSIX
numoftrades	chaîne de caractères	Nombre de négociations
lastttime	chaîne de caractères	Heure de la dernière transaction
blocktime	chaîne de caractères
high price	chaîne de caractères	Prix le plus haut dans la fenêtre
lowprice	chaîne de caractères	Prix le plus bas dans la fenêtre
rec_no	entier	Heure du début de la fenêtre
starttime	chaîne de caractères	Type d’enregistrement
lastprice	chaîne de caractères	Dernier prix de la fenêtre
startprice	chaîne de caractères	Prix de départ de la fenêtre
total_rec	chaîne de caractères	Quantité d’enregistrements affichés

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

3.9.1. Exemple de structure : script Java

# Request

{

“type”: “tradehistory”,

“security”: “LTCCAD”

}

# Response

{

“result”:”OK”,

“security”:”LTCCAD”,

“data”:[

{

“volume”:”0.9375″,

“numoftrades”:”1″,

“lastttime”:”1630497372665″,

“blocktime”:”1630497360000″,

“highprice”:”174.69″,

“lowprice”:”174.69″,

“rec_no”:1,

“starttime”:”1630497372665″,

“lastprice”:”174.69″,

“startprice”:”174.69″

}

“total_rec”:”1″,

“type”:”tradehistory”

}

3.10. Abonnement à l’état d’une paire négociée

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

Permissions : Public

Point de chute : subscribesymbolstatus

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

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

Requête

Clé	Valeur		Requis
type	chaîne de caractères	Type de données auquel s’abonner en utilisant subscribesymbolstatus comme symbole	oui

Réponse

Clé	Valeur
security	chaîne de caractères	Type de données auquel s’abonner
time		Heure de l’ordre au format POSIX
status		Nouvel état de la paire négociée

3.10.1 Exemple de structure : script Java

# Request

{

“type”: “subscribesymbolstatus”

}

# Response

{

“result”:”OK”,

“type”:”subscribesymbolstatus”

}

# OR

{

“data”: [

{

“security”: “BCHCAD”,

“time”: “1623155345213”,

“status”: “Halt”

}

“type”: “symbolstatus”

}

# OR

{

“data”: [

{

“security”: “BCHCAD”,

“time”: “1623155345213”,

“status”: “PreOpening”

}

“type”: “symbolstatus”

}

# OR

{

“data”: [

{

“security”: “BCHCAD”,

“time”: “1623155345213”,

“status”: “Normal”

}

“type”: “symbolstatus”

}

3.11. Abonnement pour les prix hauts et bas

Catégorie : Données sur le marché

Permissions : Public

Point de chute : subscribehighlow

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

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

Requête

Clé	Valeur		Requis
security	chaîne de caractères	Paire négociée à laquelle vous voulez vous abonner	oui

Réponse

Clé	Valeur
security	chaîne de caractères	Type de données auquel s’abonner
openingprice	chaîne de caractères	Prix à 01h00 ou prix après le calcul du prix à l’ouverture
highprice	chaîne de caractères	Plus haut prix d’exécution
lowprice	chaîne de caractères	Plus bas prix d’exécution
prevcloseprice	chaîne de caractères	Prix d’exécution à 01h00

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

3.11.1. Exemple de structure : script Java

# Request

{

“type”: “subscribehighlow”,

“security”: “*”

}

# Response

{

“security”: “BTCCAD”,

“prevcloseprice”: “35739.34”,

“type”: “highlow”

}

# OR

{

“openingprice”: “2388.1”,

“security”: “ETHCAD”,

“highprice”: “2388.1”,

“lowprice”: “2388.1”,

“prevcloseprice”: “2611.75”,

“type”: “highlow”

}

# OR

{

“result”: “OK”,

“security”: “*”,

“type”: “subscribehighlow”

}

3.12. Authentification

Catégorie : Authentification

Permissions : Négociation

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

Défi (challenge)

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

Réponse

Clé	Valeur
Key	chaîne de caractères	Chaîne de caractères utilisée pour chiffrer le mot de passe

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

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

3.12.1. Exemple de structure : script Java

# Request

{

“type”: “challenge”

}

# Response

{

“result”:”OK”,

“type”:”challenge”,

“key”:”MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvBXTe278Lwg2MoI7iGKolSYuF+sNFKrsZplxCN9x0kItU3KIf8+1q60ILLwLewCEf7foxzpWp32j9YYU9vNBghuJ7BHcDYTffTRcv+QdNno491j701Hq7DIw13AGCQQTRcnfclvblnytIEWoQsiUvPJcdiWgqJIX3IQGA47a+uwIDAQAB”

}

global.window = {};

const JSEncrypt = require(“jsencrypt”);

key = response[‘key’];

const encrypt = new JSEncrypt();

encrypt.setPublicKey(key);

let sign = encrypt.encrypt(‘YOUR PASSPHRASE’);

3.13. Connexion

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

Requête

Clé	Valeur		Requis
userid	chaîne de caractères	Username de l’utilisateur	oui
pass	chaîne de caractères	Phrase de passe générée à partir du défi (challenge) et des étapes ci-dessus	oui

Réponse

Clé	Valeur
result	chaîne de caractères	Si une réponse a été obtenue OK sera affiché, autrement une raison pour le rejet sera affichée.

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

3.12.1. Exemple de structure : script Java

# Request

{

“type”:”login”,

“userid”:”USERNAME”,

“pass”:”s7UW26iGE/iVfk2ihPYIcyzRqZRi/Ztb23UNMomf3xrBzGKUHKzfNwZe5PIR/0zvfevYvkJnKLQVhR4U9/kObD/Ir0z6mBfLLgFwEcRm08jYI/nk7lDU+W32PqduTOCThlkXYueQslK54vR9rKvMs=”

}

# Response – You will get a ‘result’:’OK’

{

“result”:”OK”,

“firm”:”COIN”,

“need2FA”:true,

“roles”:”OOOOO”,

“active”:”Y”,

“secondary_account”:”TESEGY0101PGHA12345″,

“type”:”login”,

“attr”:

{

“country”:””,

“tax_code”:”SR”,

“last_name”:”USER”,

“first_name”:”USER “,

“email”:”user@mail.com”

“use2fa”:”Y”,

“userid”:”user@mail.com”,

}

# Any open orders will be returned as follows

{

“refno”:”62YNMDOQ2SPSC0″,

“side”:”B”,

“orderstatus”:”Open”,

“type”:”order”,

“userid”:”user@mail.com”,

“execamount”:”0″,

“tif”:”GTC”,

“firm”:”COIN”,

“security”:”BCHCAD”,

“price”:”471.43″,

“liveqty”:”0.49031″,

“qty”:”0.49031″,

“updtime”:”1626342626369″,

“enttime”:”1626342626366″,

“category”:”STAGE”,

“execqty”:”0″,

“account”:”user@mail.com”,

“ordertype”:”LMT”

}

# Your current positions will also be returned

{

“firm”:”COIN”,

“security”:”CAD”,

“curpos”:”1013057.59″,

“cost”:”-841663670.1899977″,

“type”:”position”,

“account”:”user@mail.com”

}

{

“firm”:”COIN”,

“security”:”BCH”,

“curpos”:”128.25376″,

“cost”:”12008212.15″,

“type”:”position”,

“account”:”user@mail.com”

}

{

“firm”:”COIN”,

“security”:”LTC”,

“curpos”:”121.7144″,

“cost”:”1199785.55″,

“type”:”position”,

“account”:”user@mail.com”

}

# OR

{

“result”:”invalid user/password”,

“type”:”login”

}

3.14. Déconnexion

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

3.14.1. Exemple de structure : script Java

# Request

{

“type”:”logout”,

}

# Response

{

“result”:”OK”,

“type”:”logout”

}

Error parsing json

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

Exemple

{“result”:”error parsing json”}

Product

ATS

Legal and Regulatory Documents

Fees

Client Account Agreement

Services

Company

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

FINTRAC Registered