API 401 Unauthorized de Tradovate (token caducado)

Configura un bot para la API de Tradovate, envía algunas órdenes de demostración y todo funciona sin problemas, pero, al cabo de una hora y media, cada llamada choca de repente con un 401 Unauthorized. Es uno de los fallos más comunes y peor interpretados de la API de Tradovate, y la causa es casi siempre la misma: su token de acceso caducó silenciosamente. Los tokens de acceso de Tradovate duran aproximadamente 90 minutos. Una vez que ese plazo se agota, tanto la API REST como el WebSocket de datos de mercado dejan de confiar en usted. Lo verá como un simple estado HTTP 401 Unauthorized, un mensaje "Access is denied", o un WebSocket que envía abruptamente un frame de cierre y se desconecta. La solución no es volver a machacar el endpoint de login, sino renovar el token antes de que caduque. Puentes de automatización como PickMyTrade gestionan ese ciclo de vida del token por usted, de modo que sus alertas siguen disparándose incluso cuando un script básico se habría quedado sin funcionar.

Qué significa «401 Unauthorized»

Un 401 Unauthorized de la API de Tradovate significa que el servidor recibió su solicitud pero se negó a ejecutarla porque no pudo verificar un token de acceso válido y vigente. Se trata de un fallo de autenticación, no de un problema de permisos ni de lógica de órdenes. En esencia, la API le está diciendo: “No sé quién es usted en este momento.” En el lado REST lo verá como un estado HTTP 401. En el WebSocket de datos de mercado y de trading suele llegar como un frame con "s":401 y el texto "Access is denied", a menudo seguido del cierre del socket.

Esta es la parte que confunde a la gente: un token de acceso de Tradovate es de corta duración por diseño. Cuando se autentica mediante /auth/accessTokenRequest, la respuesta le entrega un accessToken más un expirationTime, y ese vencimiento se sitúa aproximadamente 90 minutos más adelante. Durante esa ventana, el token es su llave para cada endpoint protegido. En el momento en que caduca, la misma solicitud que funcionaba un minuto antes devuelve un 401, porque la llave ya no abre la cerradura.

Por eso el error resulta tan desconcertante la primera vez que aparece. Nada ha cambiado en su código, su API key y su secret siguen siendo correctos, y aun así las llamadas fallan. El problema es el tiempo, no la configuración. Un 401 que solo aparece después de que su aplicación lleve más de una hora en ejecución es la huella característica de un token caducado.

Principales causas del 401 Unauthorized de la API de Tradovate en 2026

1. El token de acceso caducó (el límite de 90 minutos)

Esta es, con diferencia, la causa más común. Los tokens de acceso de Tradovate tienen, según la documentación, una vida útil de unos 90 minutos desde su creación. Si su bot obtiene un token una sola vez al iniciar y nunca lo actualiza, toda solicitud posterior a esa marca de 90 minutos devuelve un 401. En la práctica, el fallo suele producirse alrededor del minuto 80, justo donde un token que nunca se renovó deja de funcionar.

2. Renovar demasiado tarde, después de que el token ya caducó

/auth/renewAccessToken solo funciona mientras su token actual sigue siendo válido. Si espera a después de la caducidad para renovar, la propia llamada de renovación falla con un 401, está intentando autenticar una renovación con una llave muerta. Una vez que un token ha caducado por completo, debe ejecutar un nuevo /auth/accessTokenRequest, no una renovación.

3. Un encabezado Authorization mal formado

Incluso un token perfectamente válido se rechaza si lo presenta de forma incorrecta. En las llamadas REST, el encabezado debe leer Authorization: Bearer <token>, la falta del prefijo Bearer o un espacio de más basta para provocar un 401. En el WebSocket, el frame authorize debe tener exactamente el formato que especifica la documentación actual (endpoint, id y luego el token, con los separadores de línea en blanco correctos). Un fallo de formato ahí produce la misma respuesta "Access is denied".

4. Entorno incorrecto (token de demostración en host en vivo, o viceversa)

Tradovate opera entornos de demostración y en vivo separados. Un token emitido para el host de demostración no autoriza solicitudes enviadas al host en vivo, y lo mismo ocurre a la inversa. Dirija un token de demostración válido hacia un endpoint en vivo (o un token en vivo hacia demostración) y aparecerá un 401 / acceso denegado, aunque el token en sí sea genuino.

5. El token quedó invalidado por un segundo inicio de sesión

Los tokens de acceso están vinculados a una sesión. Si otro proceso, un segundo script, una prueba manual o una nueva ejecución de su propio flujo de login solicita un token nuevo para la misma cuenta, puede invalidar el token que su bot todavía está usando. El bot entonces empieza a acumular errores 401 en pleno funcionamiento aunque “nada haya cambiado” de su lado. Y machacar repetidamente el endpoint de login puede activar la penalización de solicitudes de Tradovate, lo que le retrasa aún más.

Cómo solucionar el error 401 Unauthorized: paso a paso

Solucionar un token caducado: renueve antes de que muera

Solucionar un token que ya caducó

Si su token ya caducó y la renovación devuelve un 401, deje de intentar renovarlo. Ejecute de nuevo un /auth/accessTokenRequest completo para obtener un token y una caducidad totalmente nuevos, y luego retome el bucle de renovación antes de la caducidad descrito arriba. Construya su cliente de modo que un 401 en cualquier llamada dispare una única reautenticación y un solo reintento automático, no un bucle infinito, que puede activar penalizaciones por límite de solicitudes.

Solucionar el encabezado Authorization

Registre el encabezado exacto que envía su cliente y confirme que dice Authorization: Bearer <token> con un único espacio después de Bearer. En las conexiones WebSocket, verifique que el frame authorize coincide con el formato documentado actualmente antes de asumir que su token está mal. La forma más rápida de aislar esto es hacer la misma llamada en un cliente REST, Postman o curl, con un token recién emitido. Si eso funciona, el problema está en cómo su código construye la solicitud, no en el token.

Solucionar discrepancias de entorno y credenciales

Confirme que el host al que llama coincide con el entorno para el que se emitió su token (demostración frente a en vivo). Luego verifique que su API key, secret y credenciales de la app estén actualizados en el área de gestión de la API de Tradovate, regenerarlos o perder la sincronización también producirá fallos de autenticación. Inicie sesión en su cuenta de Tradovate, abra la sección de acceso a la API / complemento y confirme que su key está activa antes de culpar al token.

Tabla de solución de problemas

Prevenga esto con PickMyTrade

Gestionar manualmente un reloj de token de 90 minutos es frágil, si se pierde una renovación, su automatización enmudece justo cuando se dispara una señal. PickMyTrade se sitúa entre TradingView y Tradovate y gestiona el ciclo de vida del token por usted:

• Renovación automática de tokens, la conexión se actualiza de forma programada, de modo que una caducidad de 90 minutos nunca descarta sus órdenes.
• Enrutamiento seguro por sesión, una única conexión gestionada por cuenta evita la invalidación por login duplicado que provoca errores 401 en pleno funcionamiento.
• Solicitudes seguras frente al límite de tasa, las llamadas se espacian para respetar los límites de solicitudes de Tradovate, de modo que nunca cambia un 401 resuelto por una penalización de espera.
• Conciencia de entorno, demostración y en vivo permanecen separados, de modo que un token nunca se envía al host equivocado.

En resumen: sus alertas de TradingView llegan a Tradovate sin que usted tenga que escribir ni vigilar ni una sola línea de código de autenticación.