Penalización de tiempo p-ticket / p-time de la API de Tradovate

Cuando su bot dispara órdenes en futuros rápidos como el ES o el NQ, nada frena una estrategia automatizada de Tradovate más rápido que una respuesta repentina de p-ticket / p-time. La API deja de procesar silenciosamente sus llamadas y devuelve una “penalización de tiempo” en lugar de una ejecución. También puede ver un simple 429 Too Many Requests, un bloqueo más largo que congela su cuenta durante varios minutos, o un objeto p-captcha que le deja fuera durante aproximadamente una hora. Todo esto es el límite de frecuencia de Tradovate haciendo exactamente lo que fue diseñado para hacer: limitar a los clientes que envían solicitudes demasiado rápido.

La buena noticia es que la solución es determinista. Espere el número de segundos que le indique el servidor y, después, reenvíe la misma solicitud con el ticket adjunto. Y si prefiere no programar usted mismo esa lógica, una capa de automatización correctamente calibrada como PickMyTrade distribuye su flujo de órdenes para que la penalización rara vez llegue a activarse.

Qué significa la respuesta de penalización de tiempo «p-ticket / p-time»

Tradovate aplica límites de frecuencia de solicitudes en su API REST. Si supera un umbral, el servidor no procesa su solicitud. En su lugar, devuelve un pequeño objeto JSON que describe una penalización de tiempo. Dos campos son relevantes: p-ticket (un token de un solo uso que certifica que fue penalizado) y p-time (el número de segundos que debe esperar antes de poder intentarlo de nuevo). Recibir este objeto significa que su llamada fue rechazada, no puesta en cola. No ha ocurrido nada en el servidor, y le corresponde a su cliente esperar y reenviar la solicitud.

Esto es deliberadamente distinto de un fallo grave. La penalización es una señal de “enfríese y vuelva”. En cuanto espere los segundos de p-time indicados y reenvíe exactamente la misma solicitud incluyendo el valor de p-ticket, el servidor la acepta como su reintento autorizado. Además, Tradovate también puede devolver un simple estado HTTP 429 Too Many Requests cuando se alcanza un límite. Ambos son síntomas de la misma causa raíz: envió solicitudes más rápido de lo que permite la API.

Existe una tercera variante, más grave. Si una respuesta contiene un campo p-captcha, la propia documentación de Tradovate indica que una aplicación de terceros no puede completar la solicitud y que a los clientes “se les debe indicar que lo intenten de nuevo en una hora.” Esto suele aparecer tras repetidos inicios de sesión con credenciales incorrectas o reintentos automáticos agresivos. A diferencia de una espera normal de p-time de unos segundos, no se resuelve insistiendo contra el endpoint.

Principales causas de las penalizaciones de tiempo de Tradovate

1. Superar los límites de frecuencia de solicitudes

Tradovate aplica límites en ventanas por segundo, por minuto y por hora. Los topes suelen situarse en torno a 5.000 solicitudes por hora y unas 80 solicitudes por minuto, con un bloqueo breve (a menudo citado en torno a 20-30 segundos) la primera vez que supera un límite. Considere estas cifras como orientativas, no como norma fija. Los límites exactos pueden cambiar, así que confirme las cifras actuales en la documentación en vivo de la API de Tradovate. En el momento en que sobrepasa una ventana, el servidor deja de procesar solicitudes e impone la penalización de tiempo.

2. Reconexiones rápidas y bucles de reautenticación

Las llamadas de autenticación y reconexión de WebSocket cuentan dentro de su presupuesto de solicitudes. Un cliente que inicia sesión, se desconecta y se reautentica en un bucle cerrado puede agotar el límite únicamente con estas tareas de mantenimiento, antes incluso de colocar una orden. Las ráfagas de reconexión son una de las causas más comunes de esta penalización.

3. Modificaciones excesivas de órdenes y stops dinámicos

Cada modificación, cancelación y reemplazo es una solicitud independiente. Las estrategias que ajustan constantemente los stops, como una lógica de seguimiento que reescribe el precio de stop tick a tick en varias cuentas, generan un torrente de llamadas. Esta es una causa principal de penalizaciones en configuraciones de copy-trading y de múltiples cuentas.

4. Inicios de sesión repetidos con credenciales incorrectas (la vía del p-captcha)

Enviar repetidamente el nombre de usuario, la contraseña o las credenciales de la aplicación incorrectas no solo falla, sino que escala. Tradovate trata una avalancha de intentos de autenticación fallidos como abuso y puede devolver el objeto p-captcha, lo que le lleva a un enfriamiento de aproximadamente una hora en lugar de una espera de p-time de unos segundos.

5. Distribución en múltiples cuentas

Replicar una señal en muchas cuentas de Tradovate multiplica su número de solicitudes por la cantidad de cuentas. Lo que a usted le parece “una operación” puede traducirse en docenas de llamadas a la API en ráfaga. Sin una regulación adecuada, una flota grande alcanza rápidamente el límite horario y cada cuenta empieza a acumular penalizaciones.

Cómo solucionar las penalizaciones de tiempo de Tradovate: paso a paso

Cómo resolver una penalización p-ticket / p-time

Esta es la solución principal, y es el patrón que Tradovate documenta directamente:

• Detecte la penalización. Tras cada solicitud, revise el cuerpo de la respuesta en busca de p-ticket y p-time (y vigile un estado 429). Si están presentes, la solicitud fue rechazada.
• Lea p-time. Este es su tiempo de espera, en segundos. No reintente antes de que transcurra. Un reintento anticipado solo genera otra penalización.
• Espere la duración completa. Pause durante p-time segundos (multiplique por 1000 para obtener milisegundos si su temporizador los requiere).
• Reenvíe la solicitud original con el ticket. Envíe exactamente el mismo endpoint y payload que envió antes, pero añada el valor del ticket devuelto como campo "p-ticket" en el cuerpo.

En JavaScript, el ejemplo oficial es el siguiente:

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

Los detalles clave: mantenga el payload original idéntico, adjunte p-ticket y dispare la solicitud solo cuando p-time haya transcurrido por completo.

Cómo gestionar una respuesta p-captcha

Un campo p-captcha no es una espera breve, es una señal de alto:

• Detenga de inmediato los reintentos automáticos. Seguir llamando al endpoint mantiene el bloqueo y puede prolongarlo.
• Verifique sus credenciales. Confirme que el nombre de usuario, la contraseña y las credenciales de la aplicación o de la API sean correctos para que el siguiente intento tenga éxito.
• Espere aproximadamente una hora, según las indicaciones de Tradovate, antes de volver a intentarlo.
• Reautentíquese una sola vez, de forma limpia, tras el periodo de enfriamiento. No reanude un bucle de reintentos.

Cómo resolver un p-ticket grave o persistente

Si las esperas breves de p-time se repiten constantemente, o si su acceso a la API parece reducido o bloqueado durante un periodo prolongado, ha pasado de una penalización puntual a un problema estructural de frecuencia. Corrija la frecuencia, no el síntoma:

• Limite en el origen. Añada un token-bucket o un retardo fijo para no acercarse nunca a los límites por minuto/hora.
• Prefiera WebSockets al polling REST. Suscríbase a eventos de órdenes y posiciones en lugar de consultar repetidamente los endpoints de listas.
• Reduzca las modificaciones/cancelaciones excesivas. Agrupe o limite la frecuencia de las actualizaciones de stop en lugar de reescribirlas en cada tick.
• Escalone las reconexiones. Añada un retardo con backoff entre los intentos de reconexión para que la reautenticación no se dispare.
• Si el acceso sigue bloqueado, póngase en contacto con el soporte de Tradovate para confirmar si es necesario un restablecimiento manual. Algunas penalizaciones prolongadas no se resuelven por sí solas.

Tabla de solución de problemas

Cómo evitarlo con PickMyTrade

PickMyTrade encamina sus alertas de TradingView hacia Tradovate a través de una capa de automatización gestionada, para que nunca tenga que programar usted mismo la lógica de reintento contra la API en bruto:

• Enrutamiento seguro frente a límites de frecuencia, distribuye el flujo de órdenes para que las llamadas se mantengan por debajo de los límites por minuto y por hora de Tradovate en lugar de desembocar en una penalización.
• Reintento y backoff integrados, respeta las esperas de p-time y reenvía de forma limpia, para que una penalización pasajera no le haga perder la operación.
• Gestión de reconexiones, mantiene sesiones estables con reconexiones escalonadas, evitando las ráfagas de reautenticación que activan p-captcha.
• Regulación multi-cuenta, distribuye una sola señal entre varias cuentas sin multiplicarla directamente por encima del límite de frecuencia.