Error 404 en el endpoint liquidatePosition de la API de Tradovate

Quiere cerrar una posición desde el código, así que envía un POST al endpoint liquidate esperando un cierre limpio. En su lugar, el servidor devuelve 404 Not Found. Su token es válido, sus otras llamadas de órdenes funcionan, el JSON parece perfecto y, aun así, esta ruta en concreto se comporta como si no existiera. Es frustrante, porque parece que el endpoint está roto o falta.

No lo está. Un 404 es más limitado de lo que parece: no tiene que ver con su cuenta, su posición ni su payload. Significa que la URL exacta a la que envió el POST no coincide con ninguna ruta del servidor de Tradovate. Nueve de cada diez veces se debe a una de estas tres cosas: la ruta tiene mayúsculas/minúsculas incorrectas o está mal escrita, apunta al host equivocado, o envió el verbo HTTP incorrecto. Vamos a descartarlas en orden y luego a fijar la llamada correcta para que pueda cerrar la posición sin problemas.

Qué le está diciendo realmente un 404

Cada error HTTP apunta a una capa distinta, y confundirlos hace que edite lo que no debe. Un 404 significa que la ruta no existe. Un 401 significa que la ruta existe pero usted no estaba autorizado. Un 400 significa que la ruta y la autorización estaban bien, pero su cuerpo estaba mal formado. Un 429 significa que está alcanzando el límite de solicitudes. Así que, si tiene delante un 404 real, deje de ajustar el cuerpo JSON: el servidor nunca llegó tan lejos como para prestarle atención. Ni siquiera pudo encontrar la ruta.

Ese único hecho reduce mucho la búsqueda. Todo lo que produce un 404 está en la línea de solicitud: el método, el host, el segmento de versión y la ortografía de la ruta. Revise esos cuatro puntos y el error desaparecerá.

Causa 1: la ruta tiene mayúsculas/minúsculas incorrectas o está mal escrita

Este es el gran clásico, y atrapa a casi todo el mundo al menos una vez. Las rutas REST de Tradovate distinguen entre mayúsculas y minúsculas. La operación se escribe exactamente liquidatePosition, con l minúscula y P mayúscula en camelCase. Escríbala de otra forma y el enrutador no tendrá nada que coincidir, por lo que responderá con 404. Poner todo en minúsculas es el error clásico, normalmente porque la escribió de memoria o porque su framework normalizó la URL por usted.

La solución es aburrida pero fiable: copie el nombre de la operación directamente de la referencia de la API y péguelo, en lugar de volver a escribirlo. Basta con un solo carácter incorrecto en las mayúsculas o minúsculas. Ya de paso, revise si hay una barra final accidental o un segmento duplicado como /order/order/liquidatePosition que un generador de URL pueda colar.

Causa 2: host incorrecto o segmento de versión ausente

La URL completa tiene cuatro partes que deben ser correctas: el esquema, el host, el segmento de versión /v1 y la ruta. Al juntarlas obtiene:

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

Si omite el /v1, obtendrá un 404, ya que en la raíz de la API no hay ninguna ruta /order/liquidatePosition colgando directamente de ella. Un error tipográfico en el host provoca lo mismo, o hace fallar la resolución DNS por completo. Y no recurra al host de datos de mercado aquí: md.tradovateapi.com sirve cotizaciones, DOM y gráficos, no operaciones de órdenes, así que un host md tampoco enrutará una llamada de liquidación.

Vale la pena señalar un matiz: mezclar entornos, un token de demo contra el host real, o viceversa, suele manifestarse más como un 401 que como un 404, pero aun así merece la pena revisarlo una vez que su ruta esté limpia. Los nombres de host se actualizan de vez en cuando, así que confirme los actuales en la propia documentación para desarrolladores de Tradovate en lugar de confiar en una URL copiada de un gist antiguo.

Causa 3: envió el método HTTP incorrecto

La operación de liquidación es solo por POST. Si envía un GET, el servidor no tiene ningún manejador GET para esa ruta, lo que aparece como un error de tipo no encontrado o método no permitido, según cómo lo informe su cliente. Es fácil caer en esto si prueba pegando la URL en la barra de direcciones del navegador, eso siempre es un GET, así que aquí siempre fallará.

Pruebe con un POST real desde un cliente adecuado. También necesita las cabeceras correctas en la solicitud: Content-Type: application/json y Authorization: Bearer <yourAccessToken>. Un POST con el cuerpo en el lugar equivocado, o sin el content type JSON, puede fallar de formas que parecen un problema de enrutamiento aunque la ruta sea correcta.

Causa 4: singular o plural, ¿cuál es el real?

Aquí es de donde viene gran parte de la confusión sobre “el endpoint no existe”. La operación canónica, por posición, es la ruta en singular /order/liquidatePosition. Toma un accountId y un único contractId y cierra esa única posición neta. Esa es la ruta que encontrará documentada, y la que responde de forma constante.

Algunas bibliotecas de cliente y fragmentos de la comunidad hacen referencia a una variante plural de tipo por lotes que toma un array positions en lugar de un único contrato. Si copia un ejemplo en plural pero su destino solo expone la ruta en singular, o asume que el singular acepta un array, obtendrá un 404 o enviará un cuerpo que el endpoint ignorará. Cuando tenga dudas, use por defecto el singular /order/liquidatePosition con accountId y contractId, y verifique el nombre exacto de la operación y su forma contra la referencia de la API en vivo para la versión que está utilizando. La ortografía y la elección entre singular y plural son exactamente los dos detalles que producen un 404 en silencio.

La llamada correcta, campo por campo

Una vez que la línea de solicitud es correcta, el cuerpo es breve.

POST https://demo.tradovateapi.com/v1/order/liquidatePosition
{ "accountId": 12345, "contractId": 67890, "admin": false, "customTag50": "" }

Los dos ids son donde la gente se atasca, así que sea metódico. Llame a /account/list y lea el id del objeto de cuenta con el que quiere operar. Llame a /position/list, y cada posición abierta le entrega tanto un accountId como un contractId, junto con su cantidad neta. Copie esos números exactos, el endpoint trabaja con el par (accountId, contractId), no con un id de posición ni con una cadena de símbolo.

La trampa del admin: un 401 escondido detrás de su solución

Esta trampa atrapa a la gente justo en el momento en que resuelven el 404. El campo admin es obligatorio en el cuerpo, pero el valor que le asigne importa. Si establece admin: true cuando su usuario de API no tiene aprovisionado acceso de administrador, la llamada pasa directamente a 401 Unauthorized. Establezca admin: false y la misma solicitud se completa correctamente. Así que, a menos que sepa que su usuario tiene alcance de administrador, envíe "admin": false. Si acaba de arreglar un 404 y ahora se encuentra con un 401 en el intento inmediatamente siguiente, esta es casi siempre la razón, no su token ni el id de su cuenta.

Qué le ofrece el endpoint, y qué no

Conviene conocer algunos comportamientos antes de construir sobre esta llamada:

• Cierra toda la posición neta para ese par (accountId, contractId). Internamente coloca una orden de cierre, lo que significa que no se ejecutará si el mercado está cerrado; ejecútela durante el horario de negociación del instrumento.
• Es una llamada por contrato. Para cerrar todo en una cuenta, obtenga /position/list y recorra en bucle, disparando un liquidatePosition por cada contractId abierto. No existe un único cuerpo de “cerrar toda la cuenta” en esta ruta.
• Es seguro frente a condiciones de carrera. Si la posición ya se cerró entre su comprobación y la llamada, por ejemplo porque se ejecutó un stop, obtiene un 200 limpio con un cuerpo vacío en lugar de un error. Eso es intencionado, y es más seguro que sintetizar una orden en el lado contrario, que podría abrir accidentalmente una posición inversa.
• No devuelve orderId. Como no hay un id de orden en la respuesta, no puede leer directamente el precio de ejecución de cierre. Si necesita ese precio para el P&L, concilie con los informes de ejecución y de fills (execution reports, fill pairs) o con el registro de posiciones.

Una lista de comprobación rápida para resolver el 404

Dónde encaja PickMyTrade

La mayoría de las personas que luchan con este 404 en realidad no quieren convertirse en fontaneros de la API de Tradovate, quieren una estrategia que abra, gestione y cierre posiciones sin tener que vigilar constantemente endpoints, ids y tokens. PickMyTrade dirige las alertas de TradingView hacia Tradovate y puede cerrar o liquidar posiciones como parte de una estrategia, de modo que no tenga que construir a mano las llamadas de liquidación, perseguir ids de cuenta y de contrato, ni gestionar tokens.

• Sin llamadas de liquidación construidas a mano su estrategia abre y cierra posiciones en Tradovate sin una sola solicitud de API codificada a mano.
• Resolución de cuenta y contrato gestionada los ids que hacen tropezar a las llamadas directas se resuelven por usted.
• Autenticación gestionada los tokens y los hosts se gestionan automáticamente, así que un 401 escondido detrás de un 404 nunca se convierte en su problema.
• Enrutamiento seguro frente a los límites de solicitudes espacia el flujo de órdenes para que nada rebote contra los límites de solicitudes de Tradovate.