Los endpoints de fill/position de la API de Tradovate no devuelven datos

Sus órdenes se ejecutan sin problemas. Luego le pide a la API justo lo único que realmente necesita, el precio de ejecución o el tamaño de la posición abierta, y no le devuelve nada. Un array vacío. Un null. Un 200 OK limpio con [] en el cuerpo. Aquí hay tres llamadas que hacen tropezar a casi todo el mundo: fill/list (o fill/items) vuelve vacío, order/item funciona pero no incluye el precio de ejecución, y position/find?name=... nunca encuentra su posición. Dos de esos son problemas de formato que puede corregir en un par de minutos. Uno es una particularidad de sincronización con la que debe contar en su diseño. Y en una pequeña parte de los casos, Tradovate realmente devuelve datos de forma poco fiable, en cuyo caso lo correcto es cotejar varios endpoints y reportarlo al soporte. Separemos los tres casos.

Qué significa realmente "devuelve None"

Hay una distinción importante detrás de estos fallos, y cambia cómo los soluciona. Un 200 OK con un array vacío significa que la llamada fue aceptada, autenticada y entendida, pero el servidor simplemente no tenía datos que darle con esos parámetros. Eso casi nunca es un error de Tradovate; es un desajuste de alcance o de sincronización de su lado. Un 404, en cambio, significa que el registro concreto que pidió no es accesible en este momento, algo común en una búsqueda item?id= después de que la sesión haya rotado. Y un 401 significa que el servidor nunca llegó siquiera a buscar datos. Así que antes de concluir que “el endpoint está roto”, compruebe cuál de esos tres está recibiendo en realidad. Eso apunta directamente a la causa.

Por qué las llamadas de fill, order y position vuelven vacías

1. REST solo muestra la sesión actual

Esta es la causa principal, y atrapa a quienes prueban fuera de horario. Tradovate archiva la sesión de cada día al cierre del mercado. Una vez que eso ocurre, los endpoints de consulta REST, fill/list, order/list, fillPair/list, cashBalanceLog/list y similares, solo ven los registros de la sesión actual. Pida los fills de ayer y obtendrá un 200 con un array vacío; pida una orden archivada concreta vía order/item?id= y puede obtener un 404. No hay nada mal en su autenticación ni en su sintaxis. Los datos simplemente ya no están en la caché en vivo. La señal reveladora es que exactamente la misma llamada funcionaba bien una hora antes durante la sesión y ahora vuelve vacía.

La solución tiene dos partes. Para actividad en vivo, ejecute sus consultas dentro de la misma sesión en la que ocurrieron las operaciones. Para todo lo histórico, la conciliación de fin de día, un diario de P&L, un registro de operaciones, use la Reporting API en rpt-live.tradovateapi.com (o rpt-demo.tradovateapi.com para demo), diseñada para servir datos archivados por rango de fechas. Los endpoints de trading de propósito general no lo están.

2. /find solo funciona en entidades con campo name

Intentar localizar una posición abierta con position/find?name=MNQZ5 fallará siempre, y no porque su posición no exista. La operación /find solo está definida para entidades que tienen un campo name. Los contratos tienen uno. Los productos tienen uno. La entidad Position no lo tiene, así que una búsqueda por nombre contra ella no devuelve nada, sin importar lo que le pase. Las posiciones se indexan por contractId, un entero, no por la cadena de símbolo que ve en su gráfico.

Así que hágalo en dos pasos. Primero resuelva el símbolo a un id de contrato: contract/find?name=MNQZ5 devuelve el objeto contract, incluido su id numérico. (Para una coincidencia parcial o anticipada, contract/suggest?t=MNQ&l=10 devuelve candidatos.) Luego obtenga sus posiciones con position/list, o position/deps?masterid={accountId} para una cuenta concreta, y filtre los resultados donde contractId coincida con el id que acaba de buscar. Lea netPos para el tamaño con signo. Esa es la posición que intentaba “encontrar”.

3. El objeto order no lleva el precio de ejecución

Este es genuinamente contraintuitivo. order/item?id= devuelve la orden, su estado, lado, cantidad, tipo de orden, marcas de tiempo. Lo que no devuelve es el precio al que se ejecutó, porque una orden y su ejecución son dos registros distintos. El precio de ejecución vive en la entidad fill, en su campo price. Una orden puede producir varios fills a distintos precios, y por eso mismo el número no puede residir como un valor único en la orden.

Para obtener el precio de ejecución de una orden, vaya a los fills. Cada fill referencia su orden padre mediante un campo orderId y su instrumento mediante contractId, y lleva price, qty, action (Buy/Sell) y un timestamp. Obtenga fill/list para la sesión y haga coincidir el orderId que le interesa, o cargue directamente los fills dependientes de la orden. Para trabajo en tiempo real, la fuente más limpia son los eventos executionReport / fill del WebSocket, que llegan en el instante en que ocurre una ejecución. Si necesita P&L realizado en lugar de precios de fill en bruto, fillPair/list le da los pares buy/sell casados.

4. Endpoint correcto, parámetro incorrecto

Los endpoints de consulta de Tradovate siguen una forma estricta y sensible a mayúsculas/minúsculas, y mezclarlos produce resultados vacíos o errores que parecen problemas de datos. El patrón es: /item?id=123 para un solo registro, /items?ids=1,2,3 para varios, /list para todo lo que esté en el alcance sin parámetros, /deps?masterid=123 para los dependientes de un padre, y /ldeps?masterids=1,2 para varios padres. Una llamada como fill/items?Id=XXX rompe silenciosamente dos reglas a la vez, usa el endpoint plural /items (que espera ids=) con un parámetro Id singular y en mayúscula que el servidor no reconoce. Cambie a fill/item?id=XXX para un registro o a fill/items?ids=XXX para una lista, y mantenga el parámetro en minúsculas.

Cómo cotejar los endpoints paso a paso

Cuando una llamada de fill, order o position vuelve vacía, ejecute esta secuencia antes de asumir que la plataforma tiene la culpa. Aísla la causa en unos minutos.

Tabla de solución de problemas

El patrón fiable: sincronizar una vez, luego transmitir

Consultar REST una y otra vez preguntando “¿ya se actualizó mi posición?” es la forma frágil de hacerlo, y es una gran razón por la que la gente ve respuestas obsoletas o vacías, se pilla el endpoint entre actualizaciones. El patrón hacia el que el propio Tradovate orienta a los desarrolladores es distinto: suscribirse, no sondear.

Abra el WebSocket de trading y envíe un user/syncrequest. Como respuesta obtiene una única instantánea consolidada, cuentas, posiciones, órdenes, fills, saldos de caja, todo. A partir de ahí, el socket le envía cada cambio a medida que ocurre: un fill nuevo, una actualización de posición, un movimiento de saldo. Mantiene un modelo local sincronizado a partir de esos eventos en lugar de volver a preguntar a REST. Para el lado histórico, las operaciones que ya se archivaron fuera de la sesión en vivo, haga el backfill inicial mediante la Reporting API y luego delegue en el WebSocket todo lo que venga después. Esa combinación es lo que mantiene la visión de un bot sobre fills y posiciones completa y actualizada a la vez.

Cuándo reportarlo al soporte

La mayoría de las veces estas respuestas vacías se remontan a una de las cuatro causas anteriores, y puede corregirlas sin ayuda de nadie. Pero hay un subconjunto real donde la llamada correcta, hecha durante una sesión activa, contra una cuenta con actividad confirmada, sigue sin devolver nada, o una orden aparece como ejecutada mientras nunca aparece un registro de fill. Eso no es algo que pueda resolver con código, y merece la pena reportarlo. Al hacerlo, incluya el endpoint exacto y la cadena de consulta, el id de cuenta, la marca de tiempo UTC, si estaba en demo o en live, y el cuerpo de respuesta 200 en bruto que muestra el resultado vacío. Un reporte cotejado así se tramita mucho más rápido que “la API no funciona”.

Dónde encaja PickMyTrade

Unir búsquedas de contrato, cotejo de fills, consultas conscientes de la sesión y un bucle de sincronización por WebSocket es mucho código que escribir y mantener solo para conocer su precio de ejecución y su tamaño abierto. PickMyTrade se sitúa entre TradingView y Tradovate y gestiona esa capa por usted:

• Seguimiento en vivo de posiciones y fills, la conexión se mantiene sincronizada con el estado de su cuenta, así que no está consultando endpoints que vuelven vacíos entre actualizaciones.
• Manejo de símbolos bien hecho, la resolución de contratos y el rollover se gestionan por debajo, así que nunca cotejará el id equivocado.
• Ejecución segura por sesión, las órdenes se enrutan y confirman sin que usted tenga que gestionar manualmente las ventanas de datos archivados frente a en vivo.
• Sin código de token ni de WebSocket, la autenticación, la renovación y el flujo de sincronización se gestionan, así que sus alertas simplemente llegan a Tradovate y se ejecutan.