Les clés API donnent aux systèmes automatisés, aux bots de trading, aux scripts opérationnels, aux pipelines de reporting et aux sessions de trading FIX un accès programmatique aux comptes de votre Organisation. Cet article présente le modèle de permissions des clés API, leur association aux comptes, l'application de la gouvernance de l'Organisation aux opérations initiées par les clés, et la gouvernance de l'administration des clés elle-même.
Les clés API ne sont pas des Membres disposant d'identifiants. Elles disposent de leur propre modèle de permissions, plus simple :
Membre | Clé API | |
|---|---|---|
Authentification | Connexion individuelle avec 2FA | Identifiants de clé API |
Accès à l'interface | Oui | Non, API uniquement |
Modèle de permissions | Profil de workflow + Rôles de compte | Permissions de la clé API appliquées aux comptes sélectionnés |
Variation par compte | Oui, les rôles peuvent accorder des permissions différentes sur différents comptes | Non, les permissions de la clé s'appliquent uniformément à tous les comptes sélectionnés |
Peut initier des demandes de retrait et de transfert | Oui, si autorisé | Oui, si autorisé |
Peut approuver des demandes | Oui, sauf les leurs | Jamais |
Workflows administratifs | Oui, selon leur Profil de workflow | Jamais |
Les deux modèles sont délibérément distincts. Les Membres reçoivent des rôles, des profils et une granularité par compte, car les personnes accumulent des responsabilités variées. Les clés reposent sur un modèle plat combinant périmètre et comptes, car l'automatisation doit être ciblée, uniforme et facile à auditer en un coup d'œil.
Une clé API regroupe deux paramètres : ce qu'elle peut faire (ses permissions) et où (ses comptes).
Autorisations
Grouper | Autorisation | Ce qu'elle permet |
|---|---|---|
Fonds | Consulter les fonds | Afficher les soldes et le statut de financement |
Déposer | Générer des adresses de dépôt et consulter l'historique des dépôts | |
Retirer | Initier des demandes de retrait (voir "Gouvernance et clés API") | |
Gains | Allouer et désallouer des produits Gains | |
Ordres | Consulter les ordres ouverts | Afficher les ordres ouverts et les trades actifs |
Consulter les ordres clôturés | Afficher l'historique des ordres et les trades exécutés | |
Créer et modifier les ordres | Passer et modifier des ordres | |
Annuler et clôturer des ordres | Annuler les ordres ouverts et clôturer les positions | |
Adresses | Ajouter l’adresse de retrait | Initier des demandes d'ajout d'adresses en liste blanche |
Mettre à jour l’adresse de retrait | Initier des demandes de modification d'adresses en liste blanche | |
Données | Consulter le registre | Afficher l'historique des transactions et du registre |
Exporter les données | Exporter les données du compte à des fins de reporting et de rapprochement |
Association des comptes
Chaque clé est associée à un ou plusieurs comptes, sélectionnés à sa création et modifiables ultérieurement. Les permissions de la clé s'appliquent uniformément à chaque compte sélectionné :
Connectivité FIX
Les clés disposant de permissions sur les ordres prennent en charge la connectivité FIX pour le trading spot, en complément des API REST et WebSocket. Une session FIX hérite des mêmes permissions et de la même association de comptes que la clé sous-jacente : elle opère uniquement sur les comptes sélectionnés, dans les limites des permissions définies. Les entreprises acheminant des flux d'ordres FIX dédient généralement une clé par session, limitée aux comptes du desk concerné.
Le trading via WebSocket sur des comptes autres que le compte principal n'est pas encore disponible pour les clés API ; cette fonctionnalité reste pour l'instant réservée aux propriétaires. Les flux d'ordres automatisés sur des comptes supplémentaires doivent passer par REST ou FIX. Consultez Disponibilité et limitations.
Les paramètres de sécurité
Paramètre | Description |
|---|---|
Expiration de la clé | Date facultative à partir de laquelle la clé cesse de fonctionner |
Date de début / fin des requêtes | Restreindre les requêtes de données à une plage de dates |
Connexions WebSocket | Activer ou désactiver le flux de données en temps réel |
Fenêtre de nonce personnalisée | Réglage de la protection anti-rejeu pour les usages à haute fréquence |
Restrictions IP | Limiter l'utilisation de la clé à des adresses IP ou des plages CIDR spécifiques |
Accordez à chaque clé les permissions minimales, le moins de comptes possible et les restrictions IP les plus strictes nécessaires à son fonctionnement. Utilisez des clés distinctes par système – une pour le bot de trading, une pour le reporting – pour que chaque révocation reste chirurgicale.
La gouvernance de l'Organisation s'applique à ce que font les clés et à la façon dont elles sont gérées.
Ce que font les clés
La règle à deux catégories applicable aux Membres s'applique de la même façon aux clés :
Une clé ne peut qu'initier des demandes soumises à gouvernance. Les clés ne disposent jamais du droit d'approbation : la séparation des tâches exige qu'un Membre humain approuve chaque demande, et aucun script ne peut se substituer à ce jugement. Lorsque la politique de demande de retrait exige deux approbations, un retrait initié par une clé attend la validation de deux Membres, exactement comme le ferait une demande initiée par un Membre.
Concevez vos automatisations autour de cette asynchronie : un appel API réussi signifie que la demande a été créée, non que les fonds ont bougé. Suivez la demande jusqu'à son exécution et prenez en compte la limitation actuelle : une demande en attente ne réserve pas les fonds. Si le solde évolue pendant la validation, la demande approuvée échoue et doit être soumise à nouveau. Voir Maintenir les fonds disponibles jusqu'à l'approbation.
Les clés n'ont également aucun accès aux workflows administratifs. La gestion des accès de l'équipe, des clés API, des comptes, des adresses (hors initiation de demandes d'adresse) et des politiques est réservée aux Membres.
Gestion des clés
La création, la modification et la révocation des clés API constituent des opérations soumises à gouvernance, dans le cadre du workflow dédié Gérer les clés API, distinct de Gérer l'équipe et les accès. Cette séparation a deux implications :
Le secret de la clé n'est affiché qu'une seule fois, lors de sa création. Conservez-le en lieu sûr avant de quitter l'écran : il ne pourra pas être récupéré ultérieurement.
La modification des permissions ou des comptes associés à une clé, ainsi que sa révocation, suivent le même processus soumis à gouvernance.
L'appel a créé une demande de retrait, actuellement retenue en attente d'approbation par la politique de demande de retrait. Consultez la page Demandes : la demande y figure avec la clé comme initiateur, en attente des approbations requises de la part des membres. C'est le modèle de gouvernance qui fonctionne comme prévu : l'automatisation propose, les humains valident.
Si la demande a été approuvée mais que les fonds n'ont pas bougé, vérifiez si le solde source couvrait le montant au moment du traitement : une demande en attente ne réserve pas les fonds, et toute activité intervenue pendant la révision peut entraîner l'échec d'une demande pourtant approuvée. Soumettez à nouveau la demande une fois le solde reconstitué.
Le compte concerné ne figure pas dans le mappage de comptes de la clé. Une clé n'agit que sur les comptes qui lui sont associés. Modifiez la clé pour y ajouter le compte, en notant que l'ensemble des permissions de la clé s'y appliquera, les clés n'admettant aucune variation par compte. Si ce périmètre est trop large, créez une seconde clé limitée au nouveau compte.
Une même clé ne peut pas avoir des permissions différentes selon le compte. Créez deux clés : une clé de trading associée au compte A et une clé en lecture seule associée au compte B. Des clés plus ciblées sont aussi plus faciles à auditer et plus sûres à révoquer.
Le workflow Manage API Keys nécessite probablement une approbation, et la demande est toujours en attente. La clé est émise, et son secret affiché, uniquement une fois les approbations requises obtenues. Vérifiez le statut de la demande sur la page Demandes.
Non. L'approbation requiert toujours un Membre humain. Il s'agit d'une règle système, et non d'une politique configurable : c'est elle qui donne tout son sens à l'approbation multipartite lorsque l'automatisation initie des mouvements de fonds.