Passaggio dalla versione Beta

Le tue chiavi API esistenti non vengono revocate o riemesse. Le loro credenziali, permessi e mappatura dell'account vengono tutti mantenuti. Ciò che cambia è il modo in cui il tuo codice gestisce le richieste e legge le risposte.

Seleziona un account per ogni richiesta

Una chiave API dell'Organizzazione copre uno o più Account e non ha un valore predefinito, quindi ogni richiesta privata deve specificare a quale Account si applica. Passa account_id come parametro di query nell'URL, non nel corpo della richiesta:

Questo si applica a trading, query di bilancio e registro, storico ordini e trade, esportazioni e movimento fondi.

Leggi la nuova risposta di prelievo

WithdrawFunds restituisce approval_request_id insieme a refid:

• Un refid non significa più che il prelievo sia stato completato. L'importo viene bloccato sull'Account sorgente quando la richiesta viene inviata e si salda solo dopo l'approvazione della richiesta.
• approval_request_id è l'identificativo per l'approvazione che il prelievo sta aspettando. Memorizzalo nei tuoi registri.
• I prelievi in attesa di approvazione non compaiono in WithdrawStatus. Una richiesta che viene rifiutata o scade non crea alcun record di prelievo, quindi l'assenza da WithdrawStatus non significa mai che un prelievo non sia stato inviato.

L'automazione che considera un refid come prova di completamento segnalerà i prelievi come saldati mentre sono ancora in coda di approvazione. Consulta le chiavi API per il modello completo.

La tua Organizzazione esce dalla conversione con due set di blocchi costitutivi standard.

Profili workflow

Un Profilo workflow definisce ciò che un Membro può fare su ogni workflow governato. Ogni Membro ne detiene esattamente uno.

Ruoli account

Un Ruolo account definisce ciò che un Membro può fare sui tuoi Account. I ruoli standard coprono tutti gli Account attuali e futuri, quindi un Membro con Trade all può fare trading su un Account che crei domani.

I profili e i ruoli standard si evolvono con il prodotto: quando viene aggiunto un nuovo workflow, i Membri che ne detengono uno acquisiscono automaticamente il livello appropriato. Consulta Ruoli, profili e autorizzazioni per il modello completo.

Quando le autorizzazioni di un Membro non corrispondono a nessun profilo standard, vengono assegnate a un ruolo che possiede esattamente quelle autorizzazioni. 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 che avevi scritto accanto al Membro, quindi un Membro etichettato come “Trader” viene assegnato a un ruolo chiamato trader. I Membri senza etichetta vengono assegnati a migrated-role. Ognuno porta un badge migrato, il che significa che il nome è stato generato e puoi modificarlo.

Perché i tuoi Membri “Admin” non sono sul profilo Admin

L'etichetta “Admin” di Beta permetteva di visualizzare, avviare e approvare, ma non di completare le proprie richieste senza una seconda approvazione. Il profilo Admin include tale capacità, che è il livello Execute.

Piuttosto che concederla automaticamente, i Membri con la vecchia etichetta vengono assegnati a un ruolo chiamato beta-admin che detiene esattamente le autorizzazioni che già avevano. Spostarli ad Admin è un'unica assegnazione ogni volta che decidi di farlo.

L'Owner viene assegnato al profilo Admin, mantiene tutto ciò che aveva e acquisisce automaticamente nuovi workflow. L'Owner detiene anche Leggi tutto, che non può essere rimosso.

Se avevi deliberatamente ridotto le autorizzazioni dell'Owner, tale decisione viene mantenuta: l'Owner si converte in un ruolo che detiene le sue autorizzazioni effettive, come qualsiasi altro Membro.

• Ogni autorizzazione detenuta da ciascun Membro viene trasferita.
• Le credenziali della chiave API, le autorizzazioni e la mappatura dell'Account vengono conservate.
• Saldi, Account e proprietà dell'Account rimangono invariati.
• Le richieste di approvazione già in corso continuano, e le tue policy, le soglie di approvazione e le impostazioni “richiedi sempre approvazione” rimangono invariate.
• La verifica dell'identità non è influenzata e nessuno deve accedere di nuovo o essere nuovamente invitato.
• Solo gli Account appartenenti alla tua Organizzazione vengono convertiti. Un'autorizzazione su qualsiasi Account al di fuori di essa rimane invariata.

La richiesta è quasi certamente priva di account_id. Senza di esso, una chiamata privata non si risolve in uno degli Account della chiave e può rispondere con un risultato vuoto anziché un errore. Aggiungi account_id all'URL e ricontrolla ogni endpoint chiamato dalla tua integrazione, non solo quelli che sono visibilmente falliti. Vedi chiavi API.

La chiamata ha creato una richiesta e bloccato l'importo sull'Account di origine. La liquidazione segue l'approvazione. Traccia la richiesta con l'`approval_request_id` restituito dalla chiamata, o trovala sulla pagina Richieste. Vedi Trasferimenti e prelievi.

I Membri le cui autorizzazioni non corrispondevano a un profilo standard necessitano ciascuno di un ruolo che preservi il loro accesso, e due Membri vengono uniti in un unico ruolo solo quando le loro autorizzazioni sono identiche. I Membri a cui avevi dato etichette diverse rimangono su ruoli separati anche quando le loro autorizzazioni corrispondono, perché le etichette suggeriscono che la distinzione fosse intenzionale. I ruoli di cui non hai bisogno possono essere consolidati riassegnando i loro Membri ed eliminando il ruolo vuoto.

I Membri che amministrano l'Organizzazione, gestendo l'accesso al team, gli Account o le chiavi API, sono inseriti in Read all, perché amministrare un Account implica essere in grado di vederlo. Se ciò è più ampio di quanto desideri, sostituisci Read all con un Ruolo Account con ambito limitato agli specifici Account di cui hanno bisogno.

No. La conversione è a senso unico. Tutto ciò che produce è modificabile in seguito, quindi qualsiasi accordo di accesso che avevi può essere ricostruito utilizzando profili e ruoli.