API key

Le chiavi API non sono Membri con credenziali. Dispongono di un proprio modello di autorizzazione, più semplice:

I due modelli sono volutamente separati. I Membri ricevono ruoli, profili e granularità per account perché le persone accumulano responsabilità diverse. Le chiavi adottano un modello flat basato su scope e account perché l'automazione deve essere circoscritta, uniforme e facilmente verificabile a colpo d'occhio.

Una chiave API combina due scelte: cosa può fare (le autorizzazioni) e dove (gli account).

Permessi

Mappatura degli account

Ogni chiave è associata a uno o più account, scelti al momento della creazione e modificabili in seguito. I permessi della chiave si applicano in modo uniforme a tutti gli account selezionati:

• Una chiave con i permessi Query funds e Create and modify orders su due account selezionati può leggere i saldi e fare trading su entrambi, senza toccare altro.
• All'interno di una chiave non è possibile differenziare i permessi per account. Se la tua automazione deve fare trading su un account ma solo leggere l'altro, usa due chiavi. In questo modo il perimetro d'azione di ogni chiave rimane evidente.

Seleziona un account specifico quando necessario

Le richieste API private utilizzano l'account principale dell'organizzazione quando account_id è omesso:

Per operare su un account specifico, passa account_id come parametro di query nell'URL:

Passalo 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. Se la chiave non può operare sull'account selezionato, la richiesta viene rifiutata.

Connettività FIX

Le chiavi con permessi sugli ordini supportano la connettività FIX per il spot trading, insieme alle API REST e WebSocket. Una sessione FIX eredita gli stessi permessi e la stessa mappatura degli account della chiave associata: opera solo sugli account selezionati dalla chiave, entro i limiti dei suoi permessi. Le società che gestiscono flussi di ordini FIX dedicano in genere una chiave per sessione, circoscritta agli account su cui opera il desk.

Impostazioni di sicurezza

La governance dell'organizzazione si applica sia a ciò che le chiavi fanno sia a come vengono gestite.

Cosa fanno le chiavi

La regola delle due categorie prevista per i membri si applica allo stesso modo alle chiavi:

• Le operazioni dirette vengono eseguite immediatamente. Trading, Earn, query sui saldi, query sul ledger ed esportazione dei dati vengono eseguiti immediatamente, nei limiti delle autorizzazioni e degli account associati alla chiave.
• Le operazioni soggette a governance creano richieste. Un prelievo o una modifica di indirizzo avviati da una chiave seguono lo stesso flusso di quelli avviati da un membro: la policy del workflow stabilisce se l'operazione viene completata immediatamente o resta in coda di approvazione per la revisione umana.

Una chiave può solo avviare richieste soggette a governance. Le chiavi non dispongono mai del permesso di approvazione: la separazione dei compiti richiede un membro umano per ogni approvazione, e nessuno script può sostituire tale giudizio. Quando la policy sulle richieste di prelievo richiede due approvazioni, un prelievo avviato da una chiave attende due membri, esattamente come farebbe uno avviato da un membro.

Una chiamata andata a buon fine non equivale a un prelievo completato

Progetta la tua automazione tenendo conto di questa asincronia. WithdrawFunds restituisce approval_request_id insieme a refid:

• refid conferma che la richiesta esiste, non che i fondi siano stati trasferiti. L'importo viene bloccato sull'account di origine al momento dell'invio e si salda solo dopo l'approvazione della richiesta. Consulta I fondi vengono bloccati all'invio.
• approval_request_id è il riferimento per l'approvazione che il prelievo sta attendendo. Conservalo insieme al tuo registro del prelievo.
• I prelievi in attesa di approvazione non compaiono in WithdrawStatus. Una richiesta rifiutata o scaduta non genera alcun record di prelievo: l'assenza da WithdrawStatus non significa quindi che il prelievo non sia stato inviato.

Un sistema automatizzato che tratta un refid come prova di completamento segnalerà i prelievi come saldati mentre sono ancora in coda di approvazione; una riconciliazione che deduce "non presente in WithdrawStatus, quindi mai inviato" risulterà errata sia per le richieste in sospeso sia per quelle rifiutate.

Le chiavi non hanno inoltre accesso ai flussi di lavoro amministrativi. La gestione degli accessi del team, delle chiavi API, degli account, degli indirizzi (al di là dell'avvio delle richieste di indirizzo) e delle policy è riservata ai Membri.

Gestione delle chiavi

La creazione, la modifica e la revoca delle chiavi API è un'operazione soggetta a governance, gestita tramite il flusso di lavoro dedicato Manage API Keys, separato da Manage Team & Access. La separazione è rilevante per due motivi:

• Amministratori distinti. Puoi consentire a un tecnico operativo di gestire le chiavi senza dargli la possibilità di modificare gli accessi dei Membri, e viceversa.
• Policy distinte. La gestione delle chiavi può avere requisiti di approvazione propri. Molte organizzazioni richiedono un'approvazione indipendente per creare o modificare una chiave – una nuova credenziale è un nuovo accesso ai tuoi account – mantenendo la revoca rapida.

1. Vai a Chiavi API e seleziona Crea chiave.
2. Assegna alla chiave un nome che ne descriva lo scopo, il sistema che gestisce e le operazioni che svolge, così la sua funzione sarà chiara durante le verifiche e gli eventi di sicurezza.
3. Seleziona le autorizzazioni della chiave.
4. Seleziona gli account su cui opera la chiave. Le autorizzazioni si applicano a tutti gli account selezionati in modo uniforme.
5. Configura le impostazioni di sicurezza: scadenza, restrizioni IP, finestra nonce.
6. Rivedi e conferma. Se il criterio Gestisci chiavi API richiede un'approvazione, la richiesta rimane in attesa delle approvazioni necessarie prima che la chiave venga emessa.

La modifica delle autorizzazioni o degli account di una chiave e la revoca di una chiave seguono lo stesso percorso governato.

La chiamata ha creato una richiesta di prelievo e il criterio Richiesta di prelievo la trattiene in attesa di approvazione. Controlla la pagina Richieste: la richiesta compare lì con la chiave come iniziatore, in attesa delle approvazioni dei Membri richieste. È il modello di governance che funziona come previsto: l'automazione propone, i membri umani approvano.

L'importo viene bloccato sull'account di origine mentre la richiesta è in attesa ed è quindi già accantonato per il prelievo. Monitora la richiesta usando il valore approval_request_id restituito dalla chiamata.

L'account in errore non è incluso nella mappatura degli account della chiave. Una chiave opera esclusivamente sugli account selezionati. Modifica la chiave per aggiungere l'account, tenendo presente che l'intero set di permessi della chiave si applicherà anche lì, poiché le chiavi non supportano variazioni per account. Se l'ambito è troppo ampio, crea una seconda chiave limitata al nuovo account.

Una singola chiave non può avere autorizzazioni diverse per account. Crea due chiavi: una chiave di trading associata all'account A e una chiave di sola lettura associata all'account B. Le chiavi con ambito più ristretto sono anche più facili da verificare e più sicure da revocare.

Il workflow Gestisci chiavi API richiede probabilmente un'approvazione e la richiesta è ancora in attesa. La chiave viene emessa e il relativo segreto mostrato solo dopo aver raccolto le approvazioni necessarie. Verifica lo stato della richiesta nella pagina Richieste.

No. L'approvazione richiede sempre un Membro umano. È una regola di sistema, non una policy configurabile: garantisce che l'approvazione multi-parte resti significativa quando l'automazione avvia movimenti di fondi.