Pénalité de temps p-ticket / p-time de l'API Tradovate

Lorsque votre bot envoie des ordres sur des contrats à terme rapides comme le ES ou le NQ, rien ne bloque plus vite une stratégie Tradovate automatisée qu'une réponse soudaine p-ticket / p-time. L'API cesse silencieusement de traiter vos appels et renvoie une “pénalité de temps” au lieu d'une exécution. Vous pouvez aussi voir un simple 429 Too Many Requests, un blocage plus long qui verrouille votre compte pendant plusieurs minutes, ou un objet p-captcha qui vous exclut pendant environ une heure. Tout cela est la limitation de débit de Tradovate qui fait exactement ce pour quoi elle a été conçue : freiner les clients qui envoient des requêtes trop rapidement.

Voici la partie rassurante : la solution est déterministe. Attendez le nombre de secondes indiqué par le serveur, puis renvoyez la même requête avec le ticket joint. Et si vous préférez ne pas coder cette logique vous-même, une couche d'automatisation correctement cadencée comme PickMyTrade répartit votre flux d'ordres afin que la pénalité se déclenche rarement.

Ce que signifie la réponse de pénalité de temps « p-ticket / p-time »

Tradovate applique des limites de débit de requêtes sur son API REST. Si vous franchissez un seuil, le serveur ne traite pas votre requête. Il renvoie à la place un petit objet JSON décrivant une pénalité de temps. Deux champs comptent : p-ticket (un jeton à usage unique prouvant que vous avez été pénalisé) et p-time (le nombre de secondes à attendre avant d'être autorisé à réessayer). Recevoir cet objet signifie que votre appel a été rejeté, et non mis en file d'attente. Rien ne s'est produit côté serveur, et c'est à votre client d'attendre puis de renvoyer la requête.

Ceci diffère volontairement d'un échec définitif. La pénalité est un signal de type “patientez, puis revenez”. Dès que vous attendez les secondes de p-time indiquées et renvoyez exactement la même requête en incluant la valeur de p-ticket, le serveur l'accepte comme votre nouvelle tentative autorisée. Par ailleurs, Tradovate peut aussi renvoyer un simple statut HTTP 429 Too Many Requests lorsqu'une limite est atteinte. Les deux sont les symptômes d'une même cause : vous avez envoyé des requêtes plus vite que l'API ne le permet.

Il existe une troisième variante, plus grave. Si une réponse contient un champ p-captcha, la documentation de Tradovate elle-même indique qu'une application tierce ne peut pas finaliser la requête et que les clients “doivent être invités à réessayer dans une heure.” Cela survient généralement après des connexions répétées avec des identifiants incorrects ou des tentatives automatiques agressives. Contrairement à une attente normale de p-time de quelques secondes, ce blocage ne se lève pas en martelant l'endpoint.

Principales causes des pénalités de temps Tradovate

1. Dépassement des limites de débit de requêtes

Tradovate applique des limites sur des fenêtres par seconde, par minute et par heure. Les plafonds se situent généralement autour de 5 000 requêtes par heure et environ 80 requêtes par minute, avec un court blocage (souvent cité autour de 20 à 30 secondes) la première fois que vous dépassez une limite. Considérez ces chiffres comme indicatifs, pas comme une règle absolue. Les plafonds exacts peuvent évoluer, vérifiez donc les valeurs actuelles dans la documentation API en direct de Tradovate. Dès que vous dépassez une fenêtre, le serveur cesse de traiter les requêtes et applique la pénalité de temps.

2. Reconnexions rapides et boucles de réauthentification

Les appels d'authentification et de reconnexion WebSocket comptent dans votre budget de requêtes. Un client qui se connecte, se déconnecte et se réauthentifie dans une boucle serrée peut épuiser la limite rien qu'avec ces tâches d'entretien, avant même de placer un ordre. Les rafales de reconnexion sont l'une des causes les plus fréquentes de cette pénalité.

3. Modifications d'ordres excessives et stops suiveurs

Chaque modification, annulation et remplacement constitue une requête distincte. Les stratégies qui ajustent constamment les stops, comme une logique de trailing qui réécrit le prix du stop tick par tick sur plusieurs comptes, génèrent un torrent d'appels. C'est l'une des principales causes de pénalités pour les configurations de copy-trading et multi-comptes.

4. Connexions répétées avec des identifiants incorrects (la voie du p-captcha)

Envoyer à répétition un nom d'utilisateur, un mot de passe ou des identifiants d'application incorrects ne se contente pas d'échouer, cela s'aggrave. Tradovate considère une avalanche de tentatives d'authentification échouées comme un abus et peut renvoyer l'objet p-captcha, vous plongeant dans un temps de récupération d'environ une heure au lieu d'une attente de p-time de quelques secondes.

5. Diffusion multi-comptes

Répliquer un signal sur de nombreux comptes Tradovate multiplie votre nombre de requêtes par le nombre de comptes. Ce qui vous semble être “un seul trade” peut représenter des dizaines d'appels API en rafale. Sans cadencement, un grand parc de comptes atteint rapidement le plafond horaire et chaque compte commence à accumuler des pénalités.

Comment corriger les pénalités de temps Tradovate : étape par étape

Répondre à une pénalité p-ticket / p-time

Voici la solution principale, et c'est le schéma que Tradovate documente directement :

• Détectez la pénalité. Après chaque requête, vérifiez le corps de la réponse pour p-ticket et p-time (et surveillez un statut 429). S'ils sont présents, la requête a été rejetée.
• Lisez p-time. Il s'agit de votre délai d'attente, en secondes. Ne réessayez pas avant qu'il ne soit écoulé. Une nouvelle tentative anticipée n'apporte qu'une pénalité supplémentaire.
• Attendez la durée complète. Suspendez l'exécution pendant p-time secondes (multipliez par 1 000 pour obtenir des millisecondes si votre minuteur les attend).
• Renvoyez la requête d'origine, avec le ticket. Envoyez exactement le même endpoint et la même charge utile qu'auparavant, en ajoutant la valeur du ticket renvoyé comme champ "p-ticket" dans le corps.

En JavaScript, l'exemple officiel se présente ainsi :

// 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

Les points clés : conservez la charge utile d'origine à l'identique, joignez p-ticket, et ne déclenchez la requête qu'une fois p-time entièrement écoulé.

Gérer une réponse p-captcha

Un champ p-captcha n'est pas une courte attente, c'est un panneau stop :

• Arrêtez immédiatement les tentatives automatiques. Continuer à appeler l'endpoint maintient le blocage en place et peut le prolonger.
• Vérifiez vos identifiants. Confirmez que le nom d'utilisateur, le mot de passe et les identifiants de l'application/API sont corrects afin que la prochaine tentative aboutisse réellement.
• Attendez environ une heure, conformément aux recommandations de Tradovate, avant de réessayer.
• Réauthentifiez-vous une seule fois, proprement, après le temps de récupération. Ne relancez pas une boucle de tentatives.

Lever un p-ticket sévère ou persistant

Si de courtes attentes de p-time se répètent sans cesse, ou si votre accès à l'API semble réduit ou bloqué sur une période prolongée, vous êtes passé d'une pénalité ponctuelle à un problème structurel de débit. Corrigez le débit, pas le symptôme :

• Limitez à la source. Ajoutez un token-bucket ou un délai fixe pour ne jamais approcher des plafonds par minute/heure.
• Préférez les WebSockets au polling REST. Abonnez-vous aux événements d'ordres et de positions au lieu d'interroger sans cesse les endpoints de liste.
• Réduisez le va-et-vient de modifications/annulations. Regroupez ou temporisez les mises à jour de stop plutôt que de les réécrire à chaque tick.
• Échelonnez les reconnexions. Ajoutez un délai de backoff entre les tentatives de reconnexion pour éviter un pic de réauthentification.
• Si l'accès reste bloqué, contactez le support Tradovate pour confirmer si une réinitialisation manuelle est nécessaire. Certaines pénalités prolongées ne se lèvent pas d'elles-mêmes.

Tableau de dépannage

Comment éviter cela avec PickMyTrade

PickMyTrade achemine vos alertes TradingView vers Tradovate via une couche d'automatisation gérée, afin que vous n'ayez jamais à coder vous-même la logique de nouvelle tentative face à l'API brute :

• Routage sécurisé vis-à-vis des limites de débit, répartit le flux d'ordres pour que les appels restent sous les plafonds par minute et par heure de Tradovate au lieu de déclencher une pénalité.
• Nouvelle tentative et backoff intégrés, respecte les attentes de p-time et renvoie proprement, afin qu'une pénalité passagère ne fasse pas perdre votre trade.
• Gestion des reconnexions, maintient des sessions stables avec des reconnexions échelonnées, évitant les rafales de réauthentification qui déclenchent p-captcha.
• Cadencement multi-comptes, diffuse un seul signal sur plusieurs comptes sans vous faire dépasser directement la limite de débit par simple multiplication.