Gli endpoint fill/position dell'API Tradovate non restituiscono dati

I suoi ordini vengono eseguiti senza problemi. Poi chiede all'API l'unica cosa di cui ha davvero bisogno, il prezzo di fill o la dimensione della posizione aperta, e non le restituisce nulla. Un array vuoto. Un null. Un 200 OK pulito con [] nel corpo. Tre chiamate mandano in confusione quasi tutti qui: fill/list (o fill/items) torna vuota, order/item funziona ma non riporta il prezzo di fill, e position/find?name=... non trova mai la sua posizione. Due di questi sono problemi di formato della chiamata che può risolvere in un paio di minuti. Uno è una particolarità di tempistica con cui deve fare i conti nella progettazione. E in una piccola parte dei casi è davvero Tradovate a restituire dati in modo inaffidabile, nel qual caso la cosa giusta da fare è controllare incrociando alcuni endpoint e segnalarlo al supporto. Separiamo i tre casi.

Cosa significa davvero "restituisce None"

C'è una distinzione importante dietro questi fallimenti, e cambia il modo in cui li risolve. Un 200 OK con un array vuoto significa che la chiamata è stata accettata, autenticata e compresa, ma il server semplicemente non aveva dati da fornire con quei parametri. Questo quasi mai è un bug di Tradovate; è un disallineamento di ambito o di tempistica dal suo lato. Un 404, al contrario, significa che il record specifico richiesto non è raggiungibile in questo momento, comune in una ricerca item?id= dopo che la sessione è stata archiviata. E un 401 significa che il server non è nemmeno arrivato a cercare dati. Quindi, prima di concludere che «l'endpoint è rotto», verifichi quale di questi tre stia effettivamente ricevendo. Punta direttamente alla causa.

Perché le chiamate a fill, order e position tornano vuote

1. REST mostra solo la sessione corrente

Questa è la causa principale, e colpisce chi fa test dopo l'orario di mercato. Tradovate archivia la sessione di ogni giornata alla chiusura del mercato. Una volta accaduto, gli endpoint di interrogazione REST, fill/list, order/list, fillPair/list, cashBalanceLog/list e simili, vedono solo i record della sessione corrente. Se chiede i fill di ieri ottiene un 200 con un array vuoto; se chiede un ordine archiviato specifico tramite order/item?id= può ottenere un 404. Non c'è nulla che non va nella sua autenticazione o nella sintassi. I dati semplicemente non sono più nella cache live. Il segnale rivelatore è che la stessa identica chiamata funzionava bene un'ora prima durante la sessione e ora torna vuota.

La soluzione è in due parti. Per l'attività live, esegua le query nella stessa sessione in cui sono avvenuti i trade. Per tutto ciò che è storico, la riconciliazione di fine giornata, un diario P&L, un registro dei trade, usi la Reporting API su rpt-live.tradovateapi.com (o rpt-demo.tradovateapi.com per il demo), pensata per servire dati archiviati per intervallo di date. Gli endpoint di trading generici non lo sono.

2. /find funziona solo su entità con un campo name

Provare a individuare una posizione aperta con position/find?name=MNQZ5 fallirà ogni singola volta, e non perché la sua posizione manchi. L'operazione /find è definita solo per le entità che hanno un campo name. I contratti ne hanno uno. I prodotti ne hanno uno. L'entità Position no, quindi una ricerca per nome su di essa non restituisce nulla, qualunque cosa passi. Le posizioni sono indicizzate per contractId, un intero, non per la stringa del simbolo che vede sul grafico.

Quindi proceda in due passaggi. Prima risolva il simbolo in un id di contratto: contract/find?name=MNQZ5 restituisce l'oggetto contract, incluso il suo id numerico. (Per una corrispondenza parziale o anticipata, contract/suggest?t=MNQ&l=10 restituisce dei candidati.) Poi recuperi le sue posizioni con position/list, oppure position/deps?masterid={accountId} per un account specifico, e filtri i risultati dove contractId corrisponde all'id appena cercato. Legga netPos per la dimensione con segno. Quella è la posizione che stava cercando di «trovare».

3. L'oggetto order non riporta il prezzo di fill

Questo è davvero controintuitivo. order/item?id= restituisce l'ordine, il suo stato, il lato, la quantità, il tipo di ordine, i timestamp. Ciò che non restituisce è il prezzo a cui è stato eseguito, perché un ordine e la sua esecuzione sono due record distinti. Il prezzo di esecuzione si trova sull'entità fill, nel suo campo price. Un ordine può generare più fill a prezzi diversi, ed è esattamente per questo che il numero non può stare come valore singolo sull'ordine.

Per ottenere il prezzo di fill di un ordine, vada ai fill. Ogni fill fa riferimento al proprio ordine padre tramite un campo orderId e al proprio strumento tramite contractId, e riporta price, qty, action (Buy/Sell) e un timestamp. Recuperi fill/list per la sessione e faccia corrispondere l'orderId che le interessa, oppure carichi direttamente i fill dipendenti dell'ordine. Per il lavoro in tempo reale, la fonte più pulita sono gli eventi executionReport / fill sul WebSocket, che arrivano nell'istante stesso in cui avviene un'esecuzione. Se le serve il P&L realizzato invece dei prezzi di fill grezzi, fillPair/list le fornisce le coppie buy/sell abbinate.

4. Endpoint giusto, parametro sbagliato

Gli endpoint di interrogazione di Tradovate seguono una forma rigida, sensibile alle maiuscole/minuscole, e mescolarli produce risultati vuoti o errori che sembrano problemi di dati. Lo schema è: /item?id=123 per un singolo record, /items?ids=1,2,3 per più record, /list per tutto ciò che rientra nell'ambito senza parametri, /deps?masterid=123 per i dipendenti di un genitore, e /ldeps?masterids=1,2 per più genitori. Una chiamata come fill/items?Id=XXX viola silenziosamente due regole contemporaneamente, usa l'endpoint plurale /items (che si aspetta ids=) con un parametro Id singolare e maiuscolo che il server non riconosce. Passi a fill/item?id=XXX per un record oppure a fill/items?ids=XXX per un elenco, e mantenga il parametro in minuscolo.

Come controllare incrociando gli endpoint passo dopo passo

Quando una chiamata a fill, order o position torna vuota, esegua questa sequenza prima di dare per scontato che la colpa sia della piattaforma. Isola la causa in pochi minuti.

Tabella di risoluzione dei problemi

Lo schema affidabile: sincronizzare una volta, poi fare streaming

Interrogare REST ripetutamente chiedendo «la mia posizione è già aggiornata?» è il modo fragile di procedere, ed è uno dei motivi principali per cui si vedono risposte obsolete o vuote, si intercetta l'endpoint tra un aggiornamento e l'altro. Lo schema verso cui Tradovate stessa indirizza gli sviluppatori è diverso: iscriversi, non interrogare a ripetizione.

Apra il WebSocket di trading e invii un user/syncrequest. In risposta ottiene un unico snapshot consolidato, account, posizioni, ordini, fill, saldi di cassa, tutto quanto. Da quel momento in poi, il socket le invia ogni variazione non appena si verifica: un nuovo fill, un aggiornamento di posizione, un movimento di saldo. Mantiene un modello locale sincronizzato a partire da quegli eventi invece di reinterrogare REST. Per il lato storico, i trade già archiviati fuori dalla sessione live, esegua il backfill iniziale tramite la Reporting API, poi passi la mano al WebSocket per tutto ciò che segue. Questa combinazione è ciò che mantiene la visione di un bot su fill e posizioni sia completa che aggiornata.

Quando segnalarlo al supporto

Nella maggior parte dei casi queste risposte vuote si riconducono a una delle quattro cause sopra, e può risolverle senza l'aiuto di nessuno. Ma esiste un sottoinsieme reale in cui la chiamata corretta, effettuata durante una sessione attiva, contro un account con attività confermata, continua a non restituire nulla, oppure un ordine risulta eseguito mentre non compare mai alcun record di fill. Questo non è qualcosa che può aggirare con il codice, ed è utile segnalarlo. Quando lo fa, includa l'endpoint esatto e la query string, l'id dell'account, il timestamp UTC, se era su demo o live, e il corpo di risposta 200 grezzo che mostra il risultato vuoto. Una segnalazione così controllata incrociando i dati viene gestita molto più rapidamente di «l'API non funziona».

Dove si inserisce PickMyTrade

Mettere insieme ricerche di contratto, corrispondenza dei fill, query consapevoli della sessione e un ciclo di sincronizzazione WebSocket è molto codice da scrivere e mantenere solo per conoscere il proprio prezzo di fill e la propria dimensione aperta. PickMyTrade si colloca tra TradingView e Tradovate e gestisce questo livello al posto suo:

• Monitoraggio live di posizioni e fill, la connessione resta sincronizzata con lo stato del suo account, quindi non interroga endpoint che tornano vuoti tra un aggiornamento e l'altro.
• Gestione dei simboli fatta bene, la risoluzione dei contratti e il rollover sono gestiti sotto il cofano, quindi non farà mai corrispondere l'id sbagliato.
• Esecuzione sicura per sessione, gli ordini vengono instradati e confermati senza che debba gestire manualmente le finestre di dati archiviati contro live.
• Nessun codice per token o WebSocket, autenticazione, rinnovo e flusso di sincronizzazione sono gestiti, quindi i suoi alert raggiungono semplicemente Tradovate e vengono eseguiti.