Error 401 de la API de Tradovate en vivo: ID de dispositivo no aprobado

Configura un bot de Tradovate, lo ve operar sin fallos en la cuenta demo durante días, luego lo apunta a su cuenta en vivo financiada, y cada orden regresa con un 401 con Access is denied. Es uno de los obstáculos más comunes con los que se topan los traders de API, y casi nunca es un error en su código. Tradovate en vivo aplica una regla que la demo ignora silenciosamente: cada solicitud de autenticación debe llevar un deviceId permanente y verificado, y ese dispositivo debe aprobarse mediante un enlace enviado por correo electrónico antes de poder enrutar órdenes reales. El error aparece de un par de formas, un 401 Access is denied simple, o una respuesta 200 cuyo payload dice failureReason: UnknownReason, failureText: Access is denied, pero la causa raíz es el mismo handshake de dispositivo faltante. Aquí está el diagnóstico completo y la solución, además de cómo un puente como PickMyTrade evita por completo el trámite de aprobación de dispositivo.

Qué significa “Access Is Denied”

La respuesta Access is denied es la forma en que Tradovate le indica que la sesión o el dispositivo que realiza la solicitud no ha sido autorizado para operar en una cuenta en vivo, aunque su nombre de usuario, contraseña y secreto de API sean correctos. Por eso resulta tan confuso: las mismas credenciales que se autentican sin problemas y colocan órdenes en demo fallan de repente en cuanto cambia al host en vivo.

Puede verlo como un 401 HTTP limpio, o, de forma más engañosa, como un 200 HTTP cuyo cuerpo JSON lleva un payload de fallo como [{'s': 200, 'i': 3, 'd': {'failureReason': 'UnknownReason', 'failureText': 'Access is denied'}}]. Solo el entorno en vivo exige IDs de dispositivo verificados. Es una de las pocas diferencias entre simulación y en vivo, y la razón principal por la que los 401 aparecen en vivo pero nunca en simulación. En otras palabras, se trata de una puerta de confianza de dos factores / dispositivo, no de un cuerpo de orden roto.

Principales causas de un 401 en vivo

1. Sigue apuntando al host demo

La causa más trivial: la URL base nunca se cambió. Los tokens y los ID de cuenta demo no sirven contra el endpoint en vivo, y viceversa. Si no cambió de demo.tradovateapi.com a live.tradovateapi.com, las solicitudes fallarán para las cuentas en vivo, así de simple.

2. No está enviando un deviceId permanente

El deviceId es una cadena de hasta 64 caracteres pensada para identificar de forma única y permanente el dispositivo físico que realiza la solicitud. La demo nunca lo verifica, por lo que muchas integraciones lo omiten o generan un valor desechable en cada ejecución. En vivo eso se rechaza. Regenerar un nuevo deviceId en cada inicio de sesión también parece un dispositivo completamente nuevo y no aprobado cada vez, así que el 401 nunca desaparece.

3. El dispositivo nunca se aprobó a través del enlace del correo

Esta es la causa que más gente pasa por alto. Como Tradovate trata el deviceId como parte de su autenticación de dos factores, un dispositivo nuevo debe confirmarse fuera de banda. Recibirá un correo para aprobar el ID de dispositivo, y hasta que lo apruebe en vivo, seguirá denegando el acceso. Sin hacer clic en la aprobación, no hay acceso en vivo, punto.

4. Trasladó el accountId o accountSpec de la demo a producción

Sus cuentas en vivo y demo no comparten el mismo accountId numérico, y la cadena accountSpec también difiere (una especificación en vivo frente a una con prefijo DEMO). Reutilice los valores demo contra el host en vivo y obtendrá el mismo Access is denied, incluso después de que el dispositivo sea confiable.

5. La clave de API carece de acceso de escritura de órdenes

Si la clave o la app se aprovisionó con alcance de solo lectura o solo datos de mercado, la colocación de órdenes en vivo será denegada. La clave necesita el derecho completo de órdenes (escritura), que se obtiene mediante el complemento API Access de Tradovate y la configuración de la app.

Cómo solucionar el 401 en vivo: paso a paso

Cómo solucionar un deviceId faltante o no permanente

Cómo aprobar el dispositivo mediante el enlace enviado por correo

Cómo cambiar el host y volver a obtener los valores de la cuenta en vivo

Cómo confirmar el derecho de API Access

Tabla de resolución de problemas

Dónde encaja PickMyTrade

Si prefiere operar sus señales de TradingView en vivo sin gestionar manualmente IDs de dispositivo, correos de aprobación y cambios de endpoint, PickMyTrade se encarga del handshake con el bróker por usted:

• Conexión en vivo gestionada la gestión de confianza de dispositivo y endpoints que hace tropezar a las integraciones de API sin procesar ocurre entre bastidores, de modo que las órdenes en vivo se enrutan a la primera.
• Filtros de derechos y riesgo respeta el estado del acuerdo de datos de su cuenta y los límites de la prop firm antes de enviar cualquier orden.
• Enrutamiento seguro frente a límites de tasa espacia el flujo de órdenes para que las llamadas de autenticación y de órdenes no reboten.
• Sincronización multicuenta refleja la misma señal en varias cuentas de Tradovate sin necesidad de mantener un handshake de dispositivo independiente por bot.