Cet article s'adresse aux Organisations créées dans le cadre du modèle d'accès bêta, où un administrateur accordait les autorisations à chaque Membre individuellement. Les accès reposent désormais sur les Workflow Profiles et les Account Roles ; Kraken se charge de convertir votre Organisation.
Deux points nécessitent votre attention avant la conversion :
account_id pour sélectionner un autre compte, et considérez un appel de retrait réussi comme une demande plutôt que comme la confirmation du mouvement de fonds. Consultez la section "Vérifier le comportement de votre API" ci-dessous.La conversion ne supprime aucun accès. Toutes les autorisations détenues par chaque Membre sont conservées.
Vos clés API existantes ne sont ni révoquées ni réémises. Leurs identifiants, autorisations et association de comptes sont intégralement conservés. Les appels existants qui ne transmettent pas account_id continuent de s'exécuter sur le compte principal de l'Organisation. Vérifiez comment votre intégration sélectionne un autre compte et traite les réponses aux demandes de retrait.
Sélectionner un compte spécifique selon les besoins
Lorsque account_id est omis, une requête privée s'exécute sur le compte principal :
Bash
POST /0/private/AddOrderPour opérer sur un compte spécifique, transmettez account_id en tant que paramètre de requête dans l'URL :
Bash
POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYHTransmettez-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. Cela n'élargit pas l'association de comptes ni les autorisations de la clé.
Lire la nouvelle réponse de retrait
WithdrawFunds renvoie approval_request_id en même temps que refid :
Bash
{
"error": [],
"result": {
"refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
"approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
}
}WithdrawStatus ne signifie donc jamais qu'un retrait n'a pas été soumis.Toute automatisation traitant un refid comme preuve d'exécution signalera des retraits comme réglés alors qu'ils sont encore en attente d'approbation. Consultez Clés API pour le modèle complet.
À l'issue de la conversion, votre Organisation dispose de deux types de blocs de configuration standard.
Workflow Profiles
Un Workflow Profile définit ce qu'un membre peut faire sur chaque workflow géré. Chaque membre en détient exactement un.
Profil | Ce qu'il contient |
|---|---|
Administrateur | Tous les niveaux sur tous les workflows, y compris Execute |
Initiateur | Consulter et initier sur tous les workflows. Ne peut pas approuver |
Approver | Consulter et approuver sur tous les workflows. Ne peut pas initier |
Auditeur | Consulter sur tous les workflows. Ne peut pas agir |
Funds Manager | Consulter, initier et approuver les demandes de retrait et les demandes de transfert. Consulter et initier dans Gérer les adresses. |
Account Roles
Un Account Role définit ce qu'un membre peut faire sur vos comptes. Les rôles standard couvrent tous les comptes, présents et futurs : un membre disposant du rôle Trade all pourra trader sur un compte créé ultérieurement.
Fonction | Droits accordés sur chaque compte |
|---|---|
Lecture (tous les comptes) | Lisez attentivement |
Trading (tous les comptes) | Trader |
Fonds (tous les comptes) | Transfert, retrait, allocation Gains, désallocation Gains |
Accès complet | Toutes les autorisations du compte |
Les profils et rôles standard suivent l'évolution du produit : lorsqu'un nouveau workflow est ajouté, les Membres concernés obtiennent automatiquement le niveau approprié. Consultez Rôles, profils et autorisations pour le modèle complet.
Lorsque les autorisations d'un Membre ne correspondent à aucun profil standard, ce Membre est affecté à un rôle reprenant exactement ses droits existants. Les Membres aux autorisations identiques partagent un même rôle, de sorte que votre Organisation comptera bien moins de rôles que de Membres.
Ces rôles reprennent le libellé que vous aviez attribué au Membre : un Membre étiqueté "Trader" se retrouve ainsi sur un rôle appelé trader. Les Membres sans libellé sont affectés au rôle migrated-role. Chacun porte un badge migrated, indiquant que le nom a été généré automatiquement – vous pouvez le modifier à tout moment.
La première action à effectuer après la conversion est de renommer ces rôles pour qu'ils reflètent vos appellations réelles. Modifier un rôle efface le badge migrated.
Pourquoi vos Membres "Admin" ne sont pas sur le profil Admin
Le libellé "Admin" en version Beta permettait à un Membre de consulter, d'initier et d'approuver des demandes, mais pas de finaliser ses propres demandes sans une seconde approbation. Le profil Admin inclut bien cette capacité, qui correspond au niveau Execute.
Plutôt que de l'accorder automatiquement, les Membres portant l'ancien libellé sont affectés à un rôle nommé beta-admin reprenant exactement leurs autorisations existantes. Leur affectation au profil Admin se fait en une seule action, quand vous le souhaitez.
beta-admin est l'un de vos propres rôles : les Membres qui en disposent ne bénéficieront pas automatiquement des nouveaux workflows, contrairement aux profils standard. C'est une raison supplémentaire de passer ces rôles en revue rapidement après la conversion.
Le propriétaire est placé sur le profil Admin, conserve l'ensemble de ses droits et bénéficie automatiquement des nouveaux workflows. Le propriétaire détient également le rôle Read all, qui ne peut pas être supprimé.
Si vous aviez délibérément réduit les permissions du propriétaire, ce choix est préservé : le propriétaire bascule vers un rôle correspondant exactement à ses permissions réelles, comme tout autre membre.