Penalità di tempo p-ticket / p-time dell'API Tradovate

Quando il bot invia ordini su future veloci come ES o NQ, nulla blocca una strategia Tradovate automatizzata più rapidamente di un'improvvisa risposta p-ticket / p-time. L'API smette silenziosamente di gestire le chiamate e restituisce una “penalità di tempo” invece di un'esecuzione. Può anche comparire un semplice 429 Too Many Requests, un blocco più lungo che congela l'account per alcuni minuti, oppure un oggetto p-captcha che esclude l'accesso per circa un'ora. Tutto ciò è il rate-limiting di Tradovate che fa esattamente ciò per cui è stato progettato: frenare i client che inviano richieste troppo rapidamente.

Ecco la parte rassicurante: la soluzione è deterministica. Attenda il numero di secondi indicato dal server, quindi reinvii la stessa richiesta con il ticket allegato. E se preferisce non implementare questa logica da sé, un livello di automazione correttamente calibrato come PickMyTrade distribuisce il flusso di ordini in modo che la penalità si attivi raramente.

Cosa significa la risposta di penalità di tempo «p-ticket / p-time»

Tradovate applica limiti di frequenza delle richieste sulla sua API REST. Se si supera una soglia, il server non elabora la richiesta. Restituisce invece un piccolo oggetto JSON che descrive una penalità di tempo. Due campi sono rilevanti: p-ticket (un token monouso che dimostra che è stata applicata una penalità) e p-time (il numero di secondi da attendere prima di poter riprovare). Ricevere questo oggetto significa che la chiamata è stata rifiutata, non messa in coda. Sul server non è successo nulla, e spetta al client attendere e reinviare la richiesta.

Questo è volutamente diverso da un errore grave. La penalità è un segnale del tipo “attenda e ritorni”. Non appena attende i secondi di p-time indicati e reinvia esattamente la stessa richiesta includendo il valore di p-ticket, il server la accetta come nuovo tentativo autorizzato. Inoltre, Tradovate può anche restituire un semplice stato HTTP 429 Too Many Requests quando viene raggiunto un limite. Entrambi sono sintomi della stessa causa: sono state inviate richieste più velocemente di quanto l'API consenta.

Esiste una terza variante, più grave. Se una risposta contiene un campo p-captcha, la documentazione ufficiale di Tradovate afferma che un'applicazione di terze parti non può completare la richiesta e che ai client “deve essere indicato di riprovare tra un'ora.” Questo si verifica solitamente dopo ripetuti accessi con credenziali errate o tentativi automatici aggressivi. A differenza di una normale attesa di p-time di pochi secondi, non si risolve continuando a colpire l'endpoint.

Le principali cause delle penalità di tempo di Tradovate

1. Superamento dei limiti di frequenza delle richieste

Tradovate applica limiti su finestre al secondo, al minuto e all'ora. I tetti si attestano solitamente intorno a 5.000 richieste all'ora e circa 80 richieste al minuto, con un breve blocco (spesso citato intorno a 20-30 secondi) la prima volta che si supera un limite. Consideri questi valori come indicativi, non come regola fissa. I limiti esatti possono cambiare, quindi verifichi i numeri attuali nella documentazione API live di Tradovate. Nel momento in cui si supera una finestra, il server smette di gestire le richieste e applica la penalità di tempo.

2. Riconnessioni rapide e loop di riautenticazione

Le chiamate di autenticazione e di riconnessione WebSocket rientrano nel budget di richieste. Un client che effettua login, si disconnette e si riautentica in un loop stretto può esaurire il limite solo con queste operazioni di gestione, ancora prima di inviare un ordine. Le raffiche di riconnessione sono una delle cause più comuni di questa penalità.

3. Modifiche eccessive agli ordini e stop dinamici

Ogni modifica, cancellazione e sostituzione è una richiesta separata. Le strategie che regolano costantemente gli stop, come una logica trailing che riscrive il prezzo dello stop tick dopo tick su più account, generano un torrente di chiamate. Questa è una delle cause principali delle penalità nelle configurazioni di copy-trading e multi-account.

4. Accessi ripetuti con credenziali errate (il percorso p-captcha)

Inviare ripetutamente nome utente, password o credenziali dell'app errati non si limita a fallire, ma peggiora la situazione. Tradovate considera un'ondata di tentativi di autenticazione falliti come un abuso e può restituire l'oggetto p-captcha, facendo scattare un raffreddamento di circa un'ora anziché una semplice attesa di p-time di pochi secondi.

5. Fan-out su più account

Replicare un segnale su molti account Tradovate moltiplica il numero di richieste per il numero di account. Quello che per l'utente sembra “un solo trade” può tradursi in decine di chiamate API in un'unica raffica. Senza una corretta scansione, una flotta ampia raggiunge rapidamente il tetto orario e ogni account inizia ad accumulare penalità.

Come risolvere le penalità di tempo di Tradovate: passo dopo passo

Come soddisfare una penalità p-ticket / p-time

Questa è la soluzione principale, ed è esattamente il pattern documentato direttamente da Tradovate:

• Rilevi la penalità. Dopo ogni richiesta, controlli il corpo della risposta per p-ticket e p-time (e verifichi un eventuale stato 429). Se sono presenti, la richiesta è stata rifiutata.
• Legga p-time. È il tempo di attesa, in secondi. Non riprovi prima che sia trascorso. Un nuovo tentativo anticipato comporta solo un'ulteriore penalità.
• Attenda l'intera durata. Sospenda l'esecuzione per p-time secondi (moltiplichi per 1.000 per ottenere i millisecondi se il timer li richiede).
• Reinvii la richiesta originale, con il ticket. Invii esattamente lo stesso endpoint e lo stesso payload inviati in precedenza, aggiungendo il valore del ticket restituito come campo "p-ticket" nel body.

In JavaScript, l'esempio ufficiale è il seguente:

// You received: { "p-ticket": pTicket, "p-time": pTime }
setTimeout(async () => {
  const okResponse = await fetch(URL + '/order/placeOrder', {
    method: 'POST',
    body: JSON.stringify({
      accountSpec: yourUserName,
      accountId: yourAcctId,
      action: 'Buy',
      symbol: 'MYMM1',
      orderQty: 1,
      orderType: 'Market',
      isAutomated: true,
      'p-ticket': pTicket     // attach the ticket to the retry
    })
  })
}, 1000 * pTime)        // wait p-time seconds first

I dettagli chiave: mantenere il payload originale identico, allegare p-ticket e inviare solo dopo che p-time è completamente trascorso.

Come gestire una risposta p-captcha

Un campo p-captcha non è una breve attesa, è un segnale di stop:

• Interrompa immediatamente i tentativi automatici. Continuare a chiamare l'endpoint mantiene il blocco attivo e può prolungarlo.
• Verifichi le proprie credenziali. Confermi che nome utente, password e credenziali dell'app/API siano corretti, in modo che il tentativo successivo vada effettivamente a buon fine.
• Attenda circa un'ora, secondo le indicazioni di Tradovate, prima di riprovare.
• Si riautentichi una sola volta, in modo pulito, dopo il periodo di raffreddamento. Non riprenda un loop di tentativi.

Come risolvere un p-ticket grave o persistente

Se le brevi attese di p-time continuano a ripetersi, o se l'accesso all'API risulta ridotto o bloccato per un periodo prolungato, si è passati da una penalità isolata a un problema strutturale di frequenza. Corregga la frequenza, non il sintomo:

• Limiti alla fonte. Aggiunga un token-bucket o un ritardo fisso per non avvicinarsi mai ai limiti per minuto/ora.
• Preferisca i WebSocket al polling REST. Si abboni agli eventi di ordini e posizioni invece di interrogare ripetutamente gli endpoint di elenco.
• Riduca il churn di modifiche/cancellazioni. Raggruppi o applichi un debounce agli aggiornamenti dello stop invece di riscriverli a ogni tick.
• Scagli le riconnessioni. Aggiunga un ritardo di backoff tra i tentativi di riconnessione per evitare picchi di riautenticazione.
• Se l'accesso resta bloccato, contatti il supporto Tradovate per verificare se sia necessario un ripristino manuale. Alcune penalità prolungate non si risolvono da sole.

Tabella di risoluzione dei problemi

Come prevenirlo con PickMyTrade

PickMyTrade instrada gli avvisi TradingView verso Tradovate attraverso un livello di automazione gestito, così da non dover mai implementare da soli la logica di retry contro l'API grezza:

• Routing sicuro rispetto ai limiti di frequenza, distribuisce il flusso di ordini in modo che le chiamate restino sotto i tetti per minuto e per ora di Tradovate invece di sfociare in una penalità.
• Retry e backoff integrati, rispetta le attese di p-time e reinvia in modo pulito, così una penalità temporanea non fa perdere il trade.
• Gestione delle riconnessioni, mantiene sessioni stabili con riconnessioni scaglionate, evitando le raffiche di riautenticazione che attivano p-captcha.
• Scansione multi-account, distribuisce un singolo segnale su più account senza moltiplicarlo direttamente oltre il limite di frequenza.