Tradovate addEntitlementSubscription: account live richiesto

Avete effettuato il provisioning di un utente tramite l'API Tradovate, l'account è creato, tutto sembra pulito, ma la chiamata a addEntitlementSubscription continua a restituire Live account is required e l'entitlement dei dati di mercato non viene mai assegnato. È una delle risposte più confuse dell'intero flusso di provisioning, perché l'account esiste chiaramente e il messaggio vi indirizza nella direzione sbagliata. Ecco la versione breve: questo errore significa quasi sempre che l'utente non ha ancora firmato l'accordo sui dati di mercato non professionali. Fate firmare l'accordo, confermate che si sia sincronizzato, e la stessa chiamata andrà a buon fine. Di seguito trovate la diagnosi completa, l'ordine esatto in cui devono essere eseguite le chiamate e come un bridge come PickMyTrade elimina del tutto questa danza degli entitlement.

Cosa significa davvero "È richiesto un account live"

Prendete il messaggio alla lettera e perderete un intero pomeriggio. La risposta non dice che l'account manca, dice che l'account non è ancora idoneo a ricevere un entitlement di dati di mercato live. E il motivo più comune, di gran lunga, è un accordo sui dati di mercato mancante. Tradovate, come ogni broker di futures, deve avere in archivio un accordo sui dati di mercato CME firmato prima di poter fornire a un utente dati di borsa in tempo reale. Senza accordo, nessun entitlement, e l'API segnala questa lacuna con la stringa Live account is required.

Un dettaglio manda in confusione molte integrazioni: la richiesta non fallisce con un errore HTTP. Restituisce HTTP 200, e il vero problema si trova nel corpo JSON come valore errorText. Se il vostro script di provisioning controlla solo response.status === 200 e prosegue, registrerà un successo mentre l'entitlement non è mai stato assegnato in silenzio, e ve ne accorgerete solo quando l'utente aprirà un grafico con un simbolo vuoto, ritardato o senza quotazione. Leggete sempre il corpo della risposta.

Perché l'accordo è il vero ostacolo

I dati sui futures in tempo reale non arrivano senza burocrazia. Il CME Group richiede che ogni utente finale che riceve dati live venga classificato e accetti i termini sui dati di mercato della borsa, questo è l'“accordo” di cui parliamo qui. Gli utenti dichiarano se sono professionali o non professionali, e la stragrande maggioranza dei trader retail individuali rientra nella categoria non professionale. Questa dichiarazione, insieme ai termini accettati, è ciò che sblocca l'entitlement che la vostra chiamata API sta cercando di assegnare.

Finché l'utente non completa questo passaggio, l'account può tecnicamente esistere, può anche trattarsi di un account simulato o di valutazione, ma non può legalmente ricevere dati di borsa live. Quindi l'assegnazione dell'entitlement non ha nulla di valido a cui agganciarsi, e Tradovate la rifiuta. Questa è la stessa causa alla radice di un'intera famiglia di sintomi a valle: simboli che restano ritardati, grafici senza quotazioni e ordini rifiutati per “nessuna quotazione disponibile”. L'accordo è a monte di tutto questo.

Professionale o non professionale, in breve

Lo stato non professionale copre generalmente le persone che negoziano il proprio denaro per scopi personali. Lo stato professionale si applica a determinati usi aziendali, di consulenza o di ridistribuzione dei dati e comporta commissioni di borsa notevolmente più alte. È l'utente a dichiararlo, ed è responsabile di dichiararlo correttamente. Se un utente non è sicuro di quale sia il proprio stato, indirizzatelo ai criteri attuali della borsa invece di indovinare, la differenza di commissioni è reale e le regole cambiano.

La soluzione: fate firmare l'accordo, poi assegnate

Passaggio 1: fate firmare all'utente l'accordo sui dati di mercato non professionali

Questo è il passaggio che risolve l'errore. L'accordo viene presentato all'interno della piattaforma Tradovate in cui l'utente effettua l'accesso, di solito appare durante il primo login, nell'area account o accordi, oppure nel momento in cui l'utente prova ad attivare i dati di mercato. L'utente lo esamina, dichiara lo stato non professionale e accetta. Il testo esatto del menu cambia tra le versioni della piattaforma, quindi se state documentando questo passaggio per i vostri utenti, confermate l'etichetta attuale nell'app live invece di fissare un vecchio percorso.

Passaggio 2: aggiungete le informazioni di contatto dell'utente

Prima che l'entitlement possa essere assegnato correttamente, l'utente deve avere le informazioni di contatto registrate. Se saltate questo passaggio durante il provisioning, all'utente verrà richiesto al primo accesso, e finché non esistono, l'assegnazione dell'entitlement può bloccarsi. Popolatele come parte del vostro flusso di configurazione così che nulla a valle debba attendere.

Passaggio 3: confermate che la firma si sia effettivamente sincronizzata

Ecco il dettaglio sottile. Il controllo dell'entitlement non legge il momento in cui l'utente ha cliccato su “accetta”, legge il record dell'account salvato e sincronizzato. Concedete alla firma un momento per propagarsi e risincronizzate lo stato dell'utente prima di riprovare. Richiamare addEntitlementSubscription nello stesso millisecondo in cui l'utente accetta è un modo affidabile per ottenere di nuovo lo stesso errore a causa di una race condition. Confermate prima che l'accordo risulti firmato nei dati sincronizzati.

Passaggio 4: chiamate addEntitlementSubscription

Con l'accordo firmato e sincronizzato e le informazioni di contatto in ordine, assegnate l'entitlement. Ora la chiamata ha un account valido e idoneo a cui agganciarsi e risponde correttamente. Ricontrollate il corpo della risposta, un successo non conterrà un errorText. Se state effettuando il provisioning in batch, contrassegnate un utente come “completato” solo dopo aver verificato il corpo, non il codice di stato.

Passaggio 5: verificate che l'utente disponga ora di dati live

Chiudete il cerchio confermando che l'utente veda effettivamente quotazioni in tempo reale. Fategli aprire un simbolo del mese più vicino e verificate che sia live e non ritardato. Se l'entitlement è stato assegnato ma l'utente vede ancora dati ritardati, potrebbe essere necessario controllare anche il lato dell'abbonamento ai dati di mercato, l'entitlement e un abbonamento dati attivo sono correlati ma non identici, ed entrambi devono essere corretti per un feed live pulito.

L'ordine di provisioning che funziona

Quasi tutti i ticket “Live account is required” derivano dall'aver eseguito queste chiamate nell'ordine sbagliato o dall'averne saltata una. Mantenete la sequenza intatta:

Tabella di risoluzione dei problemi

Una nota su account prop e di valutazione

Gli account di valutazione e simulati veicolano comunque dati di borsa live, quindi il requisito dell'accordo non scompare solo perché non c'è denaro reale in gioco. Ciò che cambia è la titolarità. Molte prop firm gestiscono i dati di mercato e gli entitlement a livello centrale come parte dell'account che vi emettono, in questi casi non dovreste chiamare affatto addEntitlementSubscription, e farlo può entrare in conflitto con il modo in cui la società effettua il provisioning dei dati. Le regole variano in base alla società e al tipo di account, quindi confermate il processo attuale della vostra società prima di effettuare voi stessi il provisioning degli entitlement. Quando è la società a possedere la pipeline dei dati, la soluzione per i dati live mancanti è una richiesta di supporto a loro, non una chiamata API da parte vostra.

Evitate la lotta con gli entitlement grazie a PickMyTrade

Se il vostro obiettivo è semplicemente fare trading con i vostri segnali TradingView su un account Tradovate live, e non gestire una pipeline di provisioning, PickMyTrade si occupa dell'idraulica lato broker così non dovrete mai toccare le chiamate di entitlement:

• Connessione gestita, lo stato dell'accordo sui dati e dell'entitlement del vostro account viene rispettato prima ancora che venga inviato un ordine, quindi non dovrete eseguire il debug di un errorText in una risposta API grezza.
• Instradamento da alert a ordine, gli alert di TradingView arrivano direttamente al vostro account Tradovate senza che dobbiate scrivere o sequenziare chiamate API.
• Consapevolezza di entitlement e rischio, gli ordini rispettano lo stato dei dati del vostro account e i limiti della prop firm invece di rimbalzare per un prerequisito mancante.
• Sincronizzazione multi-account, replicate un segnale su più account senza dover risolvere di nuovo il provisioning per ciascuno.