Cosa verificare quando si valutano i broker API

Definisci “broker API” e cosa cambia quando lo utilizzi

Un broker API è un servizio di accesso al mercato o di esecuzione degli ordini in cui ci si collega in modo programmatico (tramite un’interfaccia di programmazione applicativa) invece di utilizzare un’interfaccia di trading manuale. La differenza principale è che il tuo sistema diventa responsabile della trasformazione dell’intento (istruzioni d’ordine) in effettive richieste, della gestione delle risposte e della reazione agli errori.

Per valutare oggettivamente i broker API, considera il problema su due livelli:

1. Meccanismi di integrazione (stabili, testabili): come funziona l’autenticazione, come invii le richieste, come sono strutturate le risposte e come interpreti gli stati degli ordini e delle esecuzioni.
2. Condizioni di mercato e del fornitore (variabili): cosa accade durante prezzi volatili, liquidità parziale, ritardi di rete e regole di esecuzione e costi del fornitore.

Se ti concentri solo sulla parte “API”, potresti trascurare le incertezze più importanti: la qualità dell’esecuzione e il comportamento operativo sotto stress.

Checklist: meccanismi di integrazione verificabili

Adotta un approccio basato su evidenze: richiedi o esamina la documentazione e poi esegui test con esempi controllati.

1. Autenticazione e ambito dell’account: verifica quali credenziali vengono utilizzate, come viene autorizzato l’accesso e se le chiavi API possono essere limitate in base ai permessi (ad esempio, sola lettura vs trading).

2. Modello richiesta/risposta: controlla come l’API rappresenta gli ordini — tipi di ordine, tempo di validità, campi richiesti e struttura esatta delle risposte. Definisci su quali stati puoi contare e quali campi potrebbero mancare durante guasti temporanei.

3. Idempotenza e controllo delle duplicazioni: determina come l’API previene o risolve invii ripetuti (ad esempio, tentativi successivi a timeout). Il tuo sistema deve poter evitare ordini duplicati accidentali.

4. Mappatura del ciclo di vita dell’ordine e dell’esecuzione: verifica cosa significano gli stati “accettato”, “eseguito”, “rifiutato”, “annullato” o equivalenti. Un rischio rilevante è l’incoerenza di stato — il tuo sistema potrebbe ritenere un ordine attivo mentre il broker lo ha già rifiutato.

5. Limiti di frequenza e comportamento di throttling: controlla i limiti documentati e quali risposte indicano il throttling. Pianifica come si comporterà il tuo codice quando riceve segnali di limite o backpressure.

6. Prodotti dati e timestamp: se l’API fornisce quotazioni, scambi o eventi dell’account, chiarisci il significato dei timestamp (ora del server vs ora locale) e le assunzioni sulla frequenza di aggiornamento. Senza questo, non puoi distinguere la latenza dal movimento di mercato.

7. Gestione degli errori e strategia di ripetizione: verifica come l’API comunica gli errori (livello HTTP/rete vs livello applicativo). I tuoi test dovrebbero classificare i guasti in “sicuri da riprovare”, “da riprovare con idempotenza” e “non da riprovare”.

Evidenze ed esempi: come testare senza presupporre risultati

Poiché i risultati variano in base alle condizioni, utilizza test che misurino il comportamento del tuo sistema.

• Test di integrazione black-box: invia un piccolo numero di ordini ben definiti e verifica che la tua macchina a stati interna corrisponda al ciclo di vita riportato dall’API.
• Simulazione di timeout e ripetizione (assunzione dichiarata): supponi che la tua chiamata di rete possa scadere dopo una certa soglia (scegli una soglia per il tuo ambiente). Verifica quindi se un tentativo successivo causa duplicati o se le chiavi di idempotenza (se supportate) prevengono ripetizioni.
• Scenario di riempimento parziale (assunzione dichiarata): supponi che il mercato non possa soddisfare completamente la tua dimensione. Testa come rilevi la quantità residua e come vengono forniti gli aggiornamenti successivi.
• Controlli sull’ordine degli eventi: registra la sequenza di callback/eventi dell’API e confrontala con ciò che il tuo codice si aspetta. Una modalità di errore è l’aggiornamento fuori ordine, che può corrompere le assunzioni nel tracciamento degli ordini.

Per ogni test, registra: ID delle richieste, timestamp (con fuso orario/sorgente), payload delle risposte e risultati finali di riconciliazione.

Limitazioni e rischi: almeno una modalità di errore rilevante

Si applicano importanti limitazioni anche quando la documentazione sembra chiara:

• Guasti operativi: interruzioni di rete, tempi di inattività dell’API o degrado del servizio possono causare risposte mancanti o aggiornamenti di stato ritardati. La tua automazione deve continuare in sicurezza durante l’incertezza.
• Riempimenti parziali e variabilità di esecuzione: anche con un’integrazione corretta, gli eseguiti effettivi dipendono dalla liquidità disponibile e dai meccanismi di esecuzione in quel momento.
• Incoerenza di stato (modalità di errore rilevante): il tuo sistema può mostrare ordini “in lavorazione” mentre il broker li ha già rifiutati o annullati. Questo può accadere dopo timeout, tentativi ripetuti o consegna incoerente degli eventi.
• Incertezza sui costi e sullo slippage: i risultati di esecuzione possono differire dalle relazioni storiche, poiché costi e qualità dell’esecuzione variano in base alle condizioni.

Pertanto, lo scopo della valutazione non è la previsione, ma la capacità di riconciliare ciò che è accaduto e di rilevare discrepanze.

Verifica e prossime domande prima dell’automazione

Prima di affidarti all’automazione API, richiedi una risposta chiara e verificabile indipendentemente a queste domande: