OSO de Tradovate: 'Acceso denegado' en Market Replay
El mismo bracket OSO que se ejecuta sin problemas en la demo devuelve Access is denied en Market Replay. Replay se autentica de forma diferente, y la denegación casi siempre se debe a cómo llegó el token al socket de replay.
Tiene un bracket OSO que se dispara sin problemas en la demo. Mismo código, mismo contrato, mismo body, lo apunta a Market Replay para hacer backtest de una sesión, y Tradovate le devuelve {"failureReason":"UnknownReason","failureText":"Access is denied"}. Nada cambió de su lado excepto el entorno, así que parece un error de permisos. No lo es. Replay se autentica de forma distinta a demo y live, y el “denegado” casi siempre se debe a una sola cosa: el token nunca se presentó correctamente al socket de replay, o la orden apunta a una cuenta que la sesión de replay no posee. Corrija el flujo de autenticación y el OSO que funciona en demo funcionará también en Replay. Esto es exactamente lo que ocurre y cómo solucionarlo.
Versión breve: Replay no tiene un endpoint de autenticación propio, hacer POST a
replay.tradovateapi.com/v1/auth/accessTokenRequestsolo devuelve 404. Solicite el access token en el endpoint de autenticación dedemo(olive), abrawss://replay.tradovateapi.com/v1/websocket, envíe un frameauthorizecon ese token y, a partir de ahí, dirija cada llamada, incluido su OSO, a través de ese mismo socket contra la cuenta que creó la sesión de replay.
Cómo se ve el error
La señal es que el body de la solicitud es idéntico byte a byte al de una que funciona. Dispare el OSO en demo y obtendrá un conjunto limpio de IDs de orden:
-
{"orderId":3696709628,"oso1Id":3696709629,"oso2Id":3696709630}
Envíe el mismo payload en Replay y, en lugar de IDs, obtendrá la denegación:
-
{"failureReason":"UnknownReason","failureText":"Access is denied"}
El contrato es válido para la ventana de replay (por ejemplo, MNQM2 durante una sesión que la cubre), el token se autenticó y hasta puede obtener datos de la cuenta. Solo se rechaza la colocación de la orden. Ese patrón, todo se lee bien, la escritura se deniega, es la huella de un problema de alcance de autorización, no de una credencial incorrecta.
Por qué Market Replay devuelve "Access Is Denied"
Dos particularidades de diseño del entorno de replay provocan casi todas estas denegaciones.
Replay no tiene endpoint de autenticación HTTP
En demo y live está acostumbrado a un mundo REST: hace POST a auth/accessTokenRequest, obtiene un token y luego envía órdenes por POST a order/placeOrder por HTTPS. El host de replay no funciona así. No existe auth/accessTokenRequest en replay.tradovateapi.com, así que un POST a https://replay.tradovateapi.com/v1/auth/accessTokenRequest devuelve 404 Not Found. La gente ve ese 404, asume que el endpoint se movió y empieza a adivinar URLs, cuando la respuesta real es que replay nunca tuvo uno.
El token sigue proviniendo de los endpoints de autenticación normales. Luego lo lleva al WebSocket de replay y se autoriza allí. Todo lo que sigue, suscripciones de datos de mercado, control del reloj y colocación de órdenes, viaja como mensajes enmarcados por ese único socket. Si su OSO todavía sale por HTTPS mientras su token vive en el socket, Tradovate no tiene ninguna sesión autorizada a la que asociar la orden, y obtiene “Access is denied.”
Cada sesión de replay crea una cuenta nueva y desechable
Replay no opera con su cuenta de demo ni de live. Cuando llama a replay/initializeClock, Tradovate inicia una sesión y crea una cuenta de replay completamente nueva, financiada con el initialBalance que envía. Esa cuenta existe solo durante la sesión y se descarta cuando esta termina. Solo se ejecuta una sesión de replay por usuario a la vez, y volver a llamar a initializeClock reinicia lo que estuviera en curso.
Aquí está la trampa que produce las denegaciones: su OSO debe apuntar a esa cuenta de replay, la que la sesión actual acaba de crear, no al id de su cuenta de demo, no al id de su cuenta de live, ni a un id obsoleto de una sesión que ya reinició. Apunte la orden a la cuenta equivocada y Tradovate la rechazará con la misma cadena escueta.
La solución, paso a paso
Solicite el token en la autenticación de demo o live (nunca en replay)
Autentíquese contra un endpoint de entorno real y conserve el accessToken devuelto: el trabajo de sim/backtest usa https://demo.tradovateapi.com/v1/auth/accessTokenRequest; el trabajo con credenciales live usa https://live.tradovateapi.com/v1/auth/accessTokenRequest. Envíe el conjunto completo de credenciales que su entorno espera, name, password, appId, appVersion, cid, sec, y, especialmente en live, un deviceId estable. No haga POST a ninguna ruta de autenticación de replay.tradovateapi.com; esa es la trampa del 404.
Abra el socket de replay y autorícese con ese token
Conéctese a wss://replay.tradovateapi.com/v1/websocket. Tradovate abre el stream con un frame de apertura de un solo carácter, la letra o. En cuanto lo vea, envíe el frame de autorización usando el token del paso 1: authorize\n{id}\n\n{accessToken}. Esa forma delimitada por saltos de línea, endpoint, id de solicitud, línea en blanco, body, es cómo se enmarca cada mensaje de replay. Una autorización exitosa es lo que realmente concede a su sesión el derecho a colocar órdenes en el socket. Sáltesela, y hasta un token perfectamente válido dejará la colocación de órdenes sin autorizar.
Inicialice el reloj y capture la cuenta de la sesión
Con el socket autorizado, configure la sesión de replay enviando replay/initializeClock con su ventana y velocidad: {"startTimestamp":"2019-08-26T16:43:00.000Z","speed":100,"initialBalance":51000}. speed es un porcentaje (aproximadamente 0–400), e initialBalance financia la cuenta de replay temporal. Una vez que el reloj esté en marcha, resuelva la cuenta asociada a esta sesión y guarde su id numérico. Esta es la cuenta a la que su OSO debe referirse en accountId / accountSpec, no el id que usaría en demo o live.
Envíe el OSO a través del socket de replay, contra esa cuenta
Ahora coloque el bracket como un frame de WebSocket en el mismo socket autorizado, usando la cuenta de la sesión de replay: order/placeorder\n{id}\n\n{orderBodyJson}. Mantenga el mismo body de OSO que funciona en demo, pero sustituya el id de cuenta de replay capturado en el paso 3. Cuando la cuenta y el paso de autorización coinciden, la respuesta pasa de failureText a valores reales de orderId / oso1Id / oso2Id.
Mantenga vivo el token y el socket
Los access tokens tienen una vida corta, cuente con aproximadamente 80 a 90 minutos. Una ejecución de replay larga puede superar la duración del token, y cuando caduca a mitad de sesión, la siguiente orden se lee como una denegación. Envíe frames de heartbeat periódicos para que el socket no quede inactivo, y renueve el token antes de que caduque, no después. Trate un “Access is denied” repentino en medio de una sesión que funcionaba como una probable caducidad, no como un nuevo error de permisos.
¿Sigue obteniendo "Access Is Denied"? Revise esta lista de verificación
Si el flujo de autenticación es correcto y el OSO aún no se coloca, revise esto en orden:
- Discrepancia de id de cuenta, confirme que la orden apunta a la cuenta de la sesión de replay, no a un id de demo/live ni a un id obsoleto de una sesión que ya reinició con un initializeClock más reciente.
- Permisos de la API key, la key con la que se autenticó debe tener Orders concedido, no denegado. Una key de solo lectura se autentica y lista cuentas, pero se bloquea en cuanto intenta colocar una orden.
- Device id en live, si está generando el token desde el host de live, proporcione un deviceId estable y aprobado. Demo es permisivo en esto; live no, y las credenciales difieren entre ambos.
- Frame de autorización omitido, asegúrese de haber enviado realmente authorize después del frame de apertura o y de haber recibido éxito antes de enviar cualquier orden.
- Límite de una sesión, recuerde que solo se ejecuta una sesión de replay por usuario. Si otra sesión está activa (desde la interfaz o una ejecución anterior), la suya nueva podría estar reiniciándola sin que usted lo note.
- Ventana del contrato, el símbolo debe ser válido para la fecha de replay, así que use el contrato que era el front month activo durante su startTimestamp, no el front month de hoy.
Tabla de solución de problemas
| Síntoma | Causa | Solución |
|---|---|---|
| 404 en la URL de autenticación de replay | Replay no tiene endpoint de autenticación HTTP | Obtenga el token de demo/live auth/accessTokenRequest y luego autorice el socket de replay |
| OSO devuelve {"failureText":"Access is denied"} | El socket nunca se autorizó, o la orden apunta a la cuenta equivocada | Envíe el frame de autorización después de o; apunte a la cuenta de la sesión de replay |
| Funciona en demo, denegado en Replay | La orden sigue yendo por HTTPS en lugar del socket | Envíe order/placeorder como un mensaje enmarcado en el WebSocket de replay |
| Timeout o denegación justo después de initializeClock | Uso de una cuenta antigua de una sesión reiniciada | Vuelva a resolver y use la cuenta asociada a la sesión actual |
| Una sesión que funcionaba de pronto deniega órdenes | El access token caducó a mitad de la ejecución | Envíe heartbeat al socket y renueve el token antes de ~80–90 min |
| Denegado solo al autenticarse en live | deviceId faltante/no aprobado o permiso de Orders denegado | Proporcione un device id estable y aprobado; conceda a la key el acceso a Orders |
Dónde encaja PickMyTrade
Cablear a mano la danza de token de demo a socket de replay es de donde proviene la mayoría de estas denegaciones, un frame authorize olvidado o un id de cuenta equivocado y toda la sesión rechaza órdenes. Si su objetivo es ejecutar una estrategia contra Tradovate desde alertas de TradingView en lugar de cuidar frames de WebSocket, PickMyTrade gestiona la conexión por usted: administra el token, apunta a la cuenta correcta y marca las órdenes automatizadas correctamente para que las entradas bracket se enruten sin que tenga que depurar JSON en la apertura.
Enrute brackets sin tocar la API
Comience su prueba gratuita de 5 días, vincule sus alertas y enrute brackets a Tradovate sin tocar la API.
Comience su prueba gratuita de 5 díasPreguntas frecuentes
Demo y Replay son entornos distintos con conexiones distintas. En Replay, el token debe generarse en el endpoint de autenticación de demo o live y luego presentarse a través del WebSocket de replay con un frame authorize. Si se omite ese paso de autorización, o se envía la orden contra una cuenta que la sesión no posee, el mismo body que tiene éxito en demo vuelve con failureText "Access is denied".
No hay endpoint de autenticación en el host de replay. Hacer POST a https://replay.tradovateapi.com/v1/auth/accessTokenRequest devuelve 404 por diseño. Solicite el access token en https://demo.tradovateapi.com/v1/auth/accessTokenRequest o el equivalente de live, y luego reutilice ese token para autorizar el WebSocket de replay.
A través del WebSocket. Una vez autorizado en wss://replay.tradovateapi.com/v1/websocket, cada llamada, incluida order/placeOrder, se envía como un mensaje enmarcado como order/placeorder\n{id}\n\n{body}. Las llamadas HTTP al host de replay no enrutarán sus órdenes de replay.
replay/initializeClock inicia una sesión de replay y crea una cuenta de replay desechable que se financia para la sesión y se descarta cuando termina. Solo existe una sesión de replay por usuario a la vez, y un nuevo initializeClock reinicia la anterior. Las órdenes deben apuntar a la cuenta asociada a la sesión actual; un id de cuenta obsoleto o de demo/live produce errores de acceso denegado o timeout.
Sí. Los access tokens de Tradovate tienen una vida corta, aproximadamente entre 80 y 90 minutos. Mantenga el socket activo con frames de heartbeat periódicos y renueve el token antes de que caduque para que una caducidad a mitad de sesión no se confunda con una denegación.
Puede importar, especialmente cuando se autentica contra live en lugar de demo. Live exige un deviceId estable y aprobado proporcionado en la autenticación, y las credenciales difieren entre demo y live. Si Replay funciona con un token de demo pero falla con uno de live, revise el device id y confirme que el permiso Orders de la API key esté concedido, no denegado.
Esta guía tiene fines exclusivamente educativos e informativos y no constituye asesoramiento financiero, de inversión ni de trading. Operar con futuros y otros productos apalancados conlleva un riesgo sustancial de pérdida y no es adecuado para todos los inversores. PickMyTrade es una plataforma de automatización independiente de terceros y no está afiliada con Tradovate, Inc., ni respaldada ni patrocinada por ella. Todos los nombres, logotipos y marcas relacionados son propiedad de sus respectivos dueños. Las funciones y los pasos de la plataforma cambian con el tiempo, así que confirme siempre el proceso actual en la plataforma y documentación oficiales de Tradovate antes de actuar.