Questo articolo è rivolto alle Organizzazioni create con il modello di accesso Beta, in cui un amministratore assegnava i permessi a ciascun Membro individualmente. L'accesso è ora basato su Workflow Profiles e Account Roles, e Kraken converte la tua Organizzazione per te.
Prima della conversione, tieni presenti due aspetti:
account_id per selezionare un altro account e tratta una chiamata di prelievo andata a buon fine come una richiesta, non come conferma che i fondi si siano spostati. Consulta la sezione "Verifica il comportamento della tua API" più avanti.La conversione non rimuove alcun accesso. Tutti i permessi di ciascun Membro vengono mantenuti.
Le chiavi API esistenti non vengono revocate né riemesse. Le credenziali, i permessi e la mappatura degli account vengono tutti trasferiti. Le chiamate esistenti che non includono account_id continuano a operare sull'account principale dell'Organizzazione. Verifica come la tua integrazione seleziona un altro account e legge le risposte ai prelievi.
Seleziona un account specifico quando necessario
Se account_id viene omesso, una richiesta privata opera sull'account principale:
Bash
POST /0/private/AddOrderPer operare su un account specifico, passa account_id come parametro di query nell'URL:
Bash
POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYHPassalo nell'URL, non nel corpo della richiesta. Un account_id esplicito ha la precedenza sull'account principale predefinito. Non espande la mappatura degli account né i permessi della chiave.
Leggi la nuova risposta di prelievo
WithdrawFunds restituisce approval_request_id insieme a refid:
Bash
{
"error": [],
"result": {
"refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
"approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
}
}WithdrawStatus non significa quindi che il prelievo non sia stato inviato.I sistemi automatizzati che considerano un refid come prova dell'avvenuto prelievo lo segnalerranno come completato anche quando è ancora in coda di approvazione. Consulta API keys per il modello completo.
Al termine della conversione, la tua Organizzazione dispone di due set di componenti standard.
Workflow Profiles
Un Workflow Profile definisce le azioni che un Membro può eseguire su ogni workflow gestito. Ogni Membro ne ha esattamente uno.
Profilo | Cosa include |
|---|---|
Admin | Tutti i livelli su ogni workflow, incluso Execute |
Iniziatore | Visualizzazione e avvio su ogni workflow. Non può approvare |
Approver | Visualizzazione e approvazione su ogni workflow. Non può avviare |
Società di revisione | Visualizzazione su ogni workflow. Non può operare |
Funds Manager | Visualizzazione, avvio e approvazione per Withdrawal Request e Transfer Request. Visualizzazione e avvio per Manage Addresses |
Account Roles
Un Account Role definisce le azioni che un Membro può eseguire sui tuoi account. I ruoli standard coprono tutti gli account attuali e futuri: un Membro con Trade all può fare trading su qualsiasi account creato in seguito.
Ruolo | Cosa consente su ogni account |
|---|---|
Read all | Leggi |
Trade all | Trading |
Funds all | Trasferimento, prelievo, Earn Allocate, Earn Deallocate |
Accesso completo | Tutte le autorizzazioni sull'account |
I profili e i ruoli standard si aggiornano in linea con il prodotto: quando viene aggiunto un nuovo workflow, i Membri che ne dispongono acquisiscono automaticamente il livello appropriato. Consulta Ruoli, profili e autorizzazioni per il modello completo.
Se le autorizzazioni di un Membro non corrispondono ad alcun profilo standard, il Membro viene assegnato a un ruolo che rispecchia esattamente le autorizzazioni già detenute. I Membri con autorizzazioni identiche condividono un unico ruolo, quindi la tua Organizzazione avrà molti meno ruoli che Membri.
Questi ruoli prendono il nome dall'etichetta assegnata al Membro: un Membro con etichetta "Trader" viene assegnato a un ruolo chiamato trader. I Membri senza etichetta vengono assegnati a migrated-role. Ognuno riporta il badge migrated, che indica che il nome è stato generato automaticamente e può essere modificato.
Rinominare questi ruoli in base alle denominazioni che usi realmente è il primo intervento consigliato dopo la conversione. Modificare un ruolo rimuove il badge migrated.
Perché i Membri "Admin" non sono nel profilo Admin
L'etichetta Beta "Admin" consentiva di visualizzare, avviare e approvare, ma non di completare le proprie richieste senza una seconda approvazione. Il profilo Admin include invece questa possibilità, corrispondente al livello Execute.
Anziché concederlo automaticamente, i Membri con la vecchia etichetta vengono assegnati a un ruolo denominato beta-admin con esattamente le autorizzazioni già detenute. Spostarli nel profilo Admin è un'assegnazione singola, che puoi effettuare quando lo ritieni opportuno.
beta-admin è uno dei tuoi ruoli personalizzati, quindi i Membri che lo detengono non acquisiranno automaticamente i nuovi workflow come avviene con i profili standard. Questo è un altro motivo per rivedere questi ruoli subito dopo la conversione.
Il Proprietario viene assegnato al profilo Admin, mantiene tutte le autorizzazioni precedenti e acquisisce automaticamente i nuovi workflow. Il Proprietario detiene inoltre il ruolo Leggi tutto, che non può essere rimosso.
Se hai deliberatamente ridotto le autorizzazioni del Proprietario, tale scelta viene rispettata: il Proprietario viene convertito in un ruolo con le sue autorizzazioni effettive, come qualsiasi altro Membro.