Clés API

Les clés API ne sont pas des Membres dotés d'identifiants. Elles disposent de leur propre modèle de permissions, plus simple :

Les deux modèles sont délibérément distincts. Les Membres disposent de rôles, de profils et d'une granularité par compte, car les humains cumulent des responsabilités variées. Les clés reposent sur un modèle simple (périmètre et comptes), car l'automatisation doit être ciblée, uniforme et facilement auditable.

Une clé API combine deux paramètres : ce qu'elle peut faire (ses permissions) et où (ses comptes).

Autorisations

Correspondance des comptes

Chaque clé est associée à un ou plusieurs comptes, définis à la création de la clé et modifiables ultérieurement. Les permissions de la clé s'appliquent de façon uniforme à tous les comptes sélectionnés :

• Une clé disposant des permissions Consulter les fonds et Créer et modifier des ordres sur deux comptes sélectionnés peut lire les soldes et trader sur les deux, sans accès à autre chose.
• Il n'existe aucune variation par compte au sein d'une même clé. Si votre automatisation doit trader sur un compte et uniquement lire un autre, utilisez deux clés. Le périmètre d'action de chaque clé reste ainsi parfaitement lisible.

Cibler un compte spécifique si nécessaire

Les requêtes API privées utilisent le compte principal de l'Organisation lorsque account_id est omis :

Pour opérer sur un compte spécifique, transmettez account_id en paramètre de requête dans l'URL :

Transmettez-le dans l'URL, et non dans le corps de la requête. Un account_id explicite prend la priorité sur le compte principal par défaut. Il n'étend ni la portée des comptes ni les permissions de la clé. Si la clé ne peut pas opérer sur le compte sélectionné, la requête est rejetée.

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 portée de comptes que la clé associée : elle n'opère que sur les comptes sélectionnés, dans la limite des permissions de cette clé. Les établissements qui gèrent un flux d'ordres FIX dédient généralement une clé par session, limitée aux comptes traités par le desk concerné.

Les paramètres de sécurité

La gouvernance de l'Organisation s'applique à ce que font les clés et à leur gestion.

Ce que font les clés

La règle des deux catégories qui s'applique aux Membres vaut également pour les clés :

• Les opérations directes s'exécutent immédiatement. Le trading, les Gains, les consultations de solde, les consultations du registre et les exportations de données s'exécutent immédiatement, dans la limite des permissions et des comptes associés à la clé.
• Les opérations soumises à gouvernance créent des demandes. Un retrait ou une modification d'adresse initié par une clé suit le même circuit qu'une opération initiée par un Membre : la politique du workflow détermine si l'opération s'exécute immédiatement ou est placée en file d'attente d'approbation pour validation.

Une clé ne peut qu'initier des demandes soumises à gouvernance. Les clés ne disposent jamais de la permission Approuver : la séparation des tâches exige qu'un Membre humain valide chaque opération, 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 un retrait initié par un Membre.

Un appel réussi n'équivaut pas à un retrait effectué

Concevez votre automatisation autour de cette asynchronie. WithdrawFunds renvoie approval_request_id en même temps que refid :

• refid confirme l'existence de la demande, non le transfert des fonds. Le montant est bloqué sur le compte source à la soumission et n'est réglé qu'une fois la demande approuvée. Voir Les fonds sont bloqués à la soumission.
• approval_request_id est l'identifiant de la demande d'approbation dont le retrait est en attente. Conservez-le en regard de votre propre enregistrement du retrait.
• Les retraits en attente d'approbation n'apparaissent pas dans WithdrawStatus. Une demande rejetée ou expirée ne génère aucun enregistrement de retrait ; l'absence de WithdrawStatus ne signifie donc jamais qu'un retrait n'a pas été soumis.

Une automatisation qui considère un refid comme preuve d'exécution signalera des retraits comme réglés alors qu'ils sont en file d'attente d'approbation ; un rapprochement qui en déduit "absent de WithdrawStatus, donc jamais soumis" sera erroné aussi bien pour les demandes en attente que pour les demandes rejetées.

Les clés n'ont par ailleurs aucun accès aux workflows administratifs. La gestion des accès de l'équipe, des clés API, des comptes, des adresses (au-delà de la soumission 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 sont des opérations régies par le workflow dédié Manage API Keys, distinct de Manage Team & Access. Cette séparation présente deux avantages :

• Administrateurs distincts. Vous pouvez autoriser un ingénieur opérationnel à gérer les clés sans lui donner la possibilité de modifier les accès des membres, et inversement.
• Politiques distinctes. La gestion des clés peut disposer de ses propres exigences d'approbation. De nombreuses organisations exigent une approbation indépendante pour créer ou modifier une clé – tout nouveau credential constitue un nouvel accès à vos comptes –, tout en maintenant une révocation rapide.

1. Accédez à Clés API et sélectionnez Créer une clé.
2. Donnez à la clé un nom reflétant son utilité – le système qu'elle sert et ce qu'elle fait – afin que sa fonction soit immédiatement identifiable lors des audits et des événements de sécurité.
3. Sélectionnez les autorisations de la clé.
4. Sélectionnez les comptes sur lesquels la clé opère. Les autorisations s'appliquent uniformément à tous ces comptes.
5. Configurez les paramètres de sécurité : expiration, restrictions IP, fenêtre de nonce.
6. Vérifiez et confirmez. Si la politique Gérer les clés API exige une approbation, la demande reste en attente des approbations requises avant que la clé ne soit émise.

La modification des autorisations ou des comptes d'une clé, ainsi que sa révocation, suivent le même processus de gouvernance.

L'appel a créé une demande de retrait, et la politique Demande de retrait la bloque en attente d'approbation. Consultez la page Demandes : la demande y figure avec la clé comme initiateur, en attente des approbations requises des Membres. C'est le modèle de gouvernance fonctionnant comme prévu : l'automatisation propose, les humains approuvent.

Le montant est bloqué sur le compte source pendant que la demande est en attente : il est donc déjà réservé pour le retrait. Suivez la demande à l'aide de l'approval_request_id renvoyé avec l'appel.

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. Notez que l'ensemble de ses autorisations s'y appliquera, les clés n'offrant aucune variation par compte. Si le 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 autorisations 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 également plus faciles à auditer et plus sûres à révoquer.

Le workflow Manage API Keys requiert probablement une approbation — 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. Une approbation requiert toujours l'intervention d'un membre humain. Il s'agit d'une règle système, non d'une politique configurable : c'est elle qui donne tout son sens à l'approbation multi-parties lorsqu'une automatisation initie des mouvements de fonds.