API de Tradovate: 'Access is denied' al colocar una orden

Conecta un bot a la API REST de Tradovate, sale la primera orden en vivo, y llega Access is denied. Se siente como un muro. Sus credenciales funcionaron. La autenticación le entregó un token. Incluso puede ver sus posiciones. Sin embargo, /order/placeOrder rechaza cada ejecución con ese mismo mensaje escueto, a veces como un 401, a veces como un HTTP 200 con {"failureReason":"UnknownReason","failureText":"Access is denied"}. La buena noticia: esto casi nunca es un problema de “su clave está rota”. Es uno de cuatro errores comunes y fáciles de corregir: el id de cuenta incorrecto, un permiso de Orders demasiado limitado, el host demo/live equivocado, o un flag isAutomated mal gestionado. A continuación encontrará la checklist completa, qué significa realmente el error, cada causa raíz con una solución paso a paso, y cómo PickMyTrade evita por completo esta clase de problema para que sus alertas de TradingView lleguen a Tradovate sin que usted tenga que depurar JSON en la apertura.

Qué significa "Access is denied"

Access is denied es la respuesta genérica de Tradovate que significa “esta solicitud no está autorizada para hacer eso”. La trampa es que no es un error de autenticación en el sentido habitual, puede tener un access token perfectamente válido y sin expirar y aun así recibirlo. Se produce en el punto donde Tradovate verifica si este token tiene permiso para colocar esta orden en esta cuenta. Cualquier rotura en esa cadena, un id de cuenta que el token no posee, una API key a la que nunca se le otorgaron derechos de colocación de órdenes, o un token generado contra el host demo y luego usado contra live, aparece con las mismas tres palabras.

Aquí importan dos formas de respuesta. Un 401 Access Denied puro suele apuntar al token o al host: el token expiró, se solicitó desde la base URL equivocada, o (en live) el dispositivo no está aprobado. Un 200 OK cuyo cuerpo dice {"failureReason":"UnknownReason","failureText":"Access is denied"} significa que la solicitud se autenticó correctamente, pero la orden en sí fue rechazada en la capa de permisos, típicamente por un accountId incorrecto o un permiso de Orders faltante.

Como ambas variantes muestran el mismo mensaje, es fácil perder una hora revisando contraseñas cuando el verdadero fallo está en un solo campo del cuerpo de la solicitud. Revise primero el estado HTTP y luego trabaje las causas siguientes en orden.

Principales causas de "Access is denied" al colocar una orden

1. Está enviando el nombre visible en lugar del id de cuenta numérico

Esta es, con diferencia, la causa más común. Su cuenta muestra un nombre como DEMO1235 o TRAD123456, y resulta tentador pasar el número final como accountId. Pero accountId es el id de entidad interno de Tradovate, un valor numérico independiente que no tiene relación con los dígitos del nombre visible. Si pasa el incorrecto, el token no “posee” esa cuenta y la orden se deniega.

La solución es leer ambos identificadores desde /account/list. Cada objeto de cuenta devuelve un id (el id de entidad numérico que va en accountId) y un name (la etiqueta legible que va en accountSpec). En resumen: el id de cuenta no es el número con el que su cuenta resulta estar nombrada. Nunca lo codifique fijo, siempre obténgalo dinámicamente.

2. El permiso Orders de la API key no está en Full Access

Tradovate permite delimitar una API key por capacidad. Una key puede leer posiciones, leer información de cuenta y leer la biblioteca de contratos mientras Orders sigue configurado por debajo de Full Access, lo cual basta exactamente para autenticarse, listar cuentas y parecer saludable, pero se bloquea en el instante en que intenta colocar una orden. La solución es directa: otorgue a la key Orders → Full Access en su configuración de aplicación/API de Tradovate, y luego reemita el token para que el nuevo permiso quede incorporado.

3. Generó el token en un host y está ordenando en otro

Tradovate opera dos entornos completamente separados con dos base URLs:

• Demo / simulación: https://demo.tradovateapi.com/v1
• Live: https://live.tradovateapi.com/v1

Un token solicitado desde el host demo solo es válido contra el host demo. Si apunta ese token al /order/placeOrder de live (o al revés), obtiene Access is denied. El error clásico es llamar a auth/accessTokenRequest con una base URL malformada o inconsistente, y luego preguntarse por qué falla cada orden posterior. Confirme que su llamada de auth y su llamada de orden usan la misma cadena de host, carácter por carácter, y que el host corresponde a la cuenta con la que realmente pretende operar.

4. isAutomated falta o tiene el tipo incorrecto

Si un bot, algoritmo o cualquier proceso impersonal dispara la orden, las reglas de CME exigen isAutomated: true; un humano haciendo clic en un botón de la interfaz es false. Más allá de simplemente incluir el flag, preste atención al tipo de dato. Cuando envía JSON por POST, isAutomated es un booleano (true). Pero si codifica el cuerpo como formulario (data= en lugar de json= en requests de Python), todo se serializa como cadenas, así que debe enviarse como el string "true". Un booleano que cae silenciosamente a False, o un tipo que el servidor no puede parsear, lo devuelve directo a Access is denied.

5. Formato de símbolo y (en live) un dispositivo no aprobado

Dos causas menos frecuentes completan la lista. Primero, el formato de símbolo: pasar un contrato vencido o mal formado, un código de expiración antiguo, o un símbolo continuo/de rollover que la API no puede enrutar, puede leerse como una denegación en lugar de un error claro de “símbolo inválido”. Cambiar al contrato del mes frontal activo (o a su id de contrato) lo resuelve. Segundo, el id de dispositivo en live: live exige estrictamente que las órdenes provengan de un deviceId conocido y aprobado, suministrado en auth/accessTokenRequest, mientras que demo en gran medida lo ignora. Si su código coloca órdenes en demo pero es denegado solo en live, esa es la señal.

Cómo resolver "Access is denied": paso a paso

Tabla de resolución de problemas

Dónde encaja PickMyTrade

La mayoría de los tickets de “Access is denied” provienen de construir manualmente la lógica de auth y órdenes. PickMyTrade elimina por completo esa superficie de riesgo al intermediar la conexión con Tradovate por usted:

• Auth gestionada y enrutamiento de host, el host demo/live correcto y un token nuevo y vigente se gestionan automáticamente, de modo que una sesión caducada nunca se disfraza de error de permisos.
• Resolución de cuenta y permisos, el id de cuenta numérico correcto y el permiso de Orders se resuelven a partir de su cuenta vinculada, no se adivinan a partir de un nombre visible.
• Manejo conforme de isAutomated, las órdenes automatizadas se marcan correctamente según las reglas del exchange en todo momento, sin trampas de booleano vs. string.
• Validación de símbolo y contrato, las alertas se asignan a un contrato válido y activo antes de que se envíe cualquier orden, eliminando la clase de fallo de “denegado por símbolo inválido”.