- Errori di utilizzo generali
- Errori relativi al limite di frequenza
- Errori di trading (presentazione/annullamento degli ordini)
- Errori di stato del servizio
- Errori interni
- Errori Cloudflare (rete)
Introduzione
La maggior parte delle richieste API viene completata correttamente, ma a volte può verificarsi un problema e viene restituito un messaggio di errore al posto della risposta prevista.
La nostra API genera una serie di messaggi di errore descrittivi che indicano il motivo dell'errore, fornendo suggerimenti per la soluzione appropriata.
I messaggi di errore dell'API possono essere suddivisi in vari gruppi (a seconda del tipo di errore, della causa sottostante e della soluzione ottimale), ma il formato di tali messaggi è sempre il seguente:
"Livello di gravità""Categoria dell'errore":"Messaggio di errore"
Il "Livello di gravità" può essere Errore (E) o Avviso (W). La "Categoria dell'errore" può essere Generale, API, Query, Ordine, Trade, Versamento o Servizio. Il "Messaggio di errore" può essere una stringa di testo che descrive la causa dell'errore (ad esempio Argomenti non validi).
Questo è un esempio di errore restituito per indicare che è stata utilizzata una coppia di valute non valida in una query del ticker:
EQuery:Coppia di asset sconosciuta
Ricorda che alcuni software di terze parti (app mobili, bot commerciali e così via) scelgono di nascondere l'errore originale dell'API per mostrare un errore personalizzato, quindi il formato o il contenuto dell'errore può essere diverso, a seconda del software utilizzato.
Errori di utilizzo generali
Come riferimento aggiuntivo, di seguito è riportato un esempio di codice Python per implementare l'algoritmo di firma API. La chiave pubblica API appropriata deve essere copiata e incollata dalla gestione dell'account, mentre il metodo API e i dati POST devono essere aggiornati in modo appropriato. Il valore dell'output può essere utilizzato direttamente come valore dell'intestazione HTTP API-Sign.
#!/usr/bin/env python
# Import required Python libraries
import time
import base64
import hashlib
import hmac
# Decode API private key from base64 format displayed in account management
api_secret = base64.b64decode("nmlrD83t1J+yVWKUBx9vD6j26C5zhC11tFfXpN+Ww+8oOVuGgse5AeADcvl95jYaD+UAi3D5CrVfFr8GfQ7zhA==")
# Variables (API method, nonce, and POST data)
api_path = "/0/private/TradeBalance"
api_nonce = str(int(time.time()*1000))
api_post = "nonce=" + api_nonce + "&asset=xxbt"
# Cryptographic hash algorithms
api_sha256 = hashlib.sha256(api_nonce + api_post).digest()
api_hmac = hmac.new(api_secret, api_path + api_sha256, hashlib.sha512)
# Encode signature into base64 format used in API-Sign value
api_signature = base64.b64encode(api_hmac.digest())
# API authentication signature for use in API-Sign HTTP header
print(api_signature)
Il valore SHA256 viene calcolato utilizzando il valore nonce stesso e i dati POST per il metodo API, mentre i dati POST sono costituiti sempre dalle coppie nome/valore dei parametri del metodo nonce e dell'API. Di seguito è riportato un esempio dei dati da passare a SHA256 per il metodo TradeBalance:
SHA256 = SHA256 of "1541933977000nonce=1541933977000&asset=xxbt"
Il valore della stringa passato a SHA256 non deve contenere alcun valore Null aggiuntivo (\0) e non deve essere codificato come base64 o esadecimale (ovvero il valore della stringa deve essere una stringa di testo normale).
Il percorso URI è l'intero URL del metodo API, senza il prefisso "https://api.kraken.com". Ad esempio, il percorso URI del metodo TradeBalance è la stringa "/0/private/TradeBalance" senza alcun valore Null aggiuntivo.
Il valore HMAC SHA512 viene calcolato utilizzando il percorso URI e il digest SHA256 calcolato in precedenza, con la chiave privata API decodificata in formato base64 come chiave HMAC. Di seguito è riportato un esempio dei dati da passare ad HMAC:
HMAC SHA512 con la chiave privata decodificata in formato base64 = HMAC di "/0/private/TradeBalanceSHA256"
Le uniche due intestazioni HTTP personalizzate richieste sono API-Key e API-Sign. L'intestazione API-Key è una copia esatta della chiave API pubblica della gestione degli account. L'intestazione API-Sign è il digest HMAC SHA512 codificato in formato base64.
https://support.kraken.com/hc/en-us/articles/360001148063
Ulteriori informazioni su nonce e la finestra nonce sono disponibili qui:
La soluzione consiste semplicemente nel richiedere un nuovo token di autenticazione tramite l'endpoint GetWebSocketsToken dell'API REST e utilizzare il nuovo token per tutte le richieste di sottoscrizione autenticate (private) successive.
Errori relativi al limite di frequenza
I blocchi temporanei durano circa 15 minuti. Se ricevi un errore di blocco temporaneo, attendi 15 minuti prima di inviare nuove richieste all'API. Se vengono generati più errori di nonce non valido, aumenta la finestra nonce per cercare di ridurre la frequenza di tali errori. Prova a ridurre anche la frequenza delle chiamate API private.
Errori di trading
L'errore potrebbe anche essere dovuto al fatto che le spot position con margine non sono attualmente disponibili per i residenti di determinati Paesi.
Se desideri aprire una posizione long e short per la stessa valuta, scegli coppie di trading diverse con valuta corrispondente alla valuta base o alla valuta quotata. Esempio: short XBT/USD, long XBT/EUR.
Questo limite si basa sul livello di verifica. Chiudi alcuni ordini aperti o verifica il tuo account a un livello superiore.
Questo limite si basa sul livello di verifica. Ti invitiamo a chiudere o liquidare alcune o tutte le posizioni aperte, oppure a verificare il tuo account a un livello superiore.
Errori di stato del servizio
Errori interni
Errori Cloudflare
Quando si verifica questo problema, è possibile che l'ordine venga eseguito correttamente anche se viene restituito un errore 5xx o 10xx al posto della risposta prevista. Questo avviene perché, a volte, Cloudflare genera l'errore dopo aver gestito la chiamata all'API. Pertanto, la chiamata API ha avuto esito positivo ma i risultati non sono stati restituiti correttamente tramite Cloudflare.
Puoi tentare di risolvere il problema utilizzando i riferimenti utente (il parametro userref) per tutti gli ordini. Inserendo un riferimento utente univoco per ogni ordine, puoi utilizzare il metodo OpenOrders per verificare se l'ordine è stato eseguito correttamente o meno e determinare se è necessario ripresentarlo.
Ad esempio, se una chiamata al metodo AddOrder per un limit order include il parametro "userref=12345678", una chiamata successiva al metodo OpenOrders con il parametro "userref=12345678" restituisce le informazioni sugli ordini effettuati correttamente (compreso l'ID ordine), ma non restituisce alcuna informazione su quelli non riusciti (anche solo "result":"open":).