Cet article s'adresse aux Organisations créées dans le cadre du modèle d'accès Bêta, où un administrateur accordait individuellement des autorisations à chaque Membre. L'accès est désormais basé sur les Workflow Profiles et les Account Roles, et Kraken convertit votre Organisation pour vous.
Deux choses nécessitent votre attention avant la conversion :
Rien dans la conversion ne supprime l'accès. Toutes les autorisations détenues par chaque Membre sont transférées.
Vos clés API existantes ne sont ni révoquées ni réémises. Leurs identifiants, autorisations et mappage de compte sont tous transférés. Ce qui change, c'est la façon dont votre code traite les requêtes et lit les réponses.
Sélectionnez un compte pour chaque requête
Une clé API d'Organisation couvre un ou plusieurs Comptes et n'a pas de valeur par défaut, chaque requête privée doit donc spécifier à quel Compte elle s'applique. Transmettez account_id en tant que paramètre de requête dans l'URL, et non dans le corps de la requête :
Bash
POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYHCeci s'applique au trading, aux requêtes de solde et de grand livre, à l'historique des ordres et des transactions, aux exportations, et aux mouvements de fonds.
Testez chaque chemin d'appel dans un environnement de non-production avant de basculer, y compris ceux que vous ne vous attendez pas à voir changer. Une requête privée qui omet account_id peut renvoyer un résultat réussi mais vide plutôt qu'une erreur, ce qui peut facilement être interprété à tort comme un Compte sans activité.
Lisez la nouvelle réponse de retrait
WithdrawFunds renvoie approval_request_id avec refid :
Bash
{
"error": [],
"result": {
"refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
"approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
}
}WithdrawStatus ne signifie jamais qu'un retrait n'a pas été soumis.L'automatisation qui traite un refid comme preuve d'achèvement signalera les retraits comme réglés alors qu'ils sont encore dans la file d'attente d'approbation. Consultez Clés API pour le modèle complet.
Votre Organisation sort de la conversion avec deux ensembles de blocs de construction 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 |
|---|---|
Admin | Chaque niveau sur chaque workflow, y compris Execute |
Initiator | Afficher et Initier sur chaque workflow. Ne peut pas approuver |
Approver | Afficher et Approuver sur chaque workflow. Ne peut pas initier |
Auditor | Afficher sur chaque workflow. Ne peut pas agir |
Funds Manager | Afficher, Initier et Approuver les Demandes de retrait et les Demandes de transfert. Afficher et Initier la Gestion des 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 actuels et futurs, de sorte qu'un Membre qui a accès à « Trade all » peut effectuer des transactions sur un Compte que vous créez demain.
Rôle | Ce que cela octroie sur chaque compte |
|---|---|
Tout lire | Lire |
Tout trader | Trader |
Gérer tous les fonds | Transférer, Retirer, Allouer des gains, Désallouer des gains |
Accès complet | Toutes les autorisations de compte |
Les profils et rôles standards évoluent avec le produit : lorsqu'un nouveau flux de travail est ajouté, les Membres qui en possèdent un acquièrent automatiquement le niveau approprié. Voir Rôles, profils et autorisations pour le modèle complet.
Lorsqu'un Membre n'a pas d'autorisations correspondant à un profil standard, il est placé sur un rôle détenant exactement ce qu'il avait. Les Membres avec des autorisations identiques partagent un seul rôle, votre Organisation aura donc beaucoup moins de rôles que de Membres.
Ces rôles tirent leur nom de l'étiquette que vous aviez écrite à côté du Membre, ainsi, un Membre étiqueté « Trader » se retrouve sur un rôle appelé trader. Les Membres sans étiquette se retrouvent sur migrated-role. Chacun porte un badge migré, ce qui signifie que le nom a été généré et que vous êtes libre de le modifier.
Renommer ces rôles pour correspondre à la façon dont vous désignez réellement ces personnes est la meilleure première tâche après la conversion. La modification d'un rôle supprime le badge migré.
Pourquoi vos Membres « Admin » ne sont pas sur le profil Admin
L'ancienne étiquette « Admin » de la version Bêta permettait de visualiser, d'initier et d'approuver, mais pas de compléter leurs propres requêtes sans une seconde approbation. Le profil Admin inclut cette capacité, qui est le niveau Exécution.
Plutôt que de l'accorder automatiquement, les Membres avec l'ancienne étiquette sont placés sur un rôle nommé beta-admin détenant exactement les autorisations qu'ils avaient déjà. Les déplacer vers Admin est une seule affectation, à tout moment que vous déciderez.
beta-admin est l'un de vos propres rôles, ainsi les Membres qui le détiennent n'acquerront pas automatiquement de nouveaux flux de travail comme le font les profils standards. C'est une autre raison d'examiner ces rôles peu après la conversion.
Le Propriétaire est placé sur le profil Admin, conserve toutes ses autorisations et acquiert automatiquement les nouveaux flux de travail. Le Propriétaire détient également Tout lire, ce qui ne peut être retiré.
Si vous aviez délibérément réduit les autorisations du Propriétaire, cette décision est conservée : le Propriétaire est converti en un rôle détenant ses autorisations réelles, comme tout autre Membre.