Tradovate addEntitlementSubscription: se requiere cuenta en vivo

Ha aprovisionado un usuario a través de la API de Tradovate, la cuenta está creada, todo parece correcto, pero su llamada a addEntitlementSubscription sigue devolviendo Live account is required y el entitlement de datos de mercado nunca se asigna. Es una de las respuestas más confusas de todo el flujo de aprovisionamiento, porque la cuenta claramente sí existe y el mensaje lo lleva en la dirección equivocada. Aquí la versión breve: ese error casi siempre significa que el usuario todavía no ha firmado el acuerdo de datos de mercado no profesional. Consiga ese acuerdo firmado, confirme que se sincronizó, y la misma llamada funcionará. A continuación, el diagnóstico completo, el orden exacto en que deben ejecutarse las llamadas y cómo un puente como PickMyTrade evita por completo este baile de entitlements.

Qué significa realmente "Se requiere una cuenta en vivo"

Tome el mensaje al pie de la letra y perderá toda una tarde. La respuesta no le dice que la cuenta no existe, le dice que la cuenta todavía no es elegible para recibir un entitlement de datos de mercado en vivo. Y el motivo más común, con diferencia, es un acuerdo de datos de mercado faltante. Tradovate, como todo bróker de futuros, debe tener registrado un acuerdo de datos de mercado de CME firmado antes de poder entregar a un usuario datos de bolsa en tiempo real. Sin acuerdo, no hay entitlement, y la API reporta ese vacío con la cadena Live account is required.

Un detalle hace tropezar a muchas integraciones: la solicitud no falla con un error HTTP. Devuelve HTTP 200, y el problema real está dentro del cuerpo JSON como un valor errorText. Si su script de aprovisionamiento solo verifica response.status === 200 y continúa, registrará un éxito mientras el entitlement nunca se asignó en silencio, y no lo descubrirá hasta que el usuario abra un gráfico con un símbolo en blanco, retrasado o sin cotización. Lea siempre el cuerpo de la respuesta.

Por qué el acuerdo es el verdadero obstáculo

Los datos de futuros en tiempo real no llegan sin papeleo. CME Group exige que todo usuario final que reciba datos en vivo esté clasificado y acepte los términos de datos de mercado de la bolsa, eso es el “acuerdo” del que hablamos aquí. Los usuarios declaran si son profesionales o no profesionales, y la inmensa mayoría de los traders minoristas individuales caen en la categoría no profesional. Esa declaración, junto con los términos aceptados, es lo que desbloquea el entitlement que su llamada a la API intenta asignar.

Hasta que el usuario complete ese paso, la cuenta puede existir técnicamente, incluso puede ser una cuenta simulada o de evaluación, pero legalmente no se le puede entregar datos de bolsa en vivo. Así que la asignación del entitlement no tiene nada válido a lo que engancharse, y Tradovate la rechaza. Esta es la misma causa raíz detrás de toda una familia de síntomas derivados: símbolos que se quedan retrasados, gráficos sin cotizaciones y órdenes rechazadas por “no hay cotización disponible”. El acuerdo está en el origen de todo esto.

Profesional o no profesional, brevemente

El estatus no profesional generalmente cubre a personas que operan con su propio dinero con fines personales. El estatus profesional se aplica a ciertos usos comerciales, de asesoría o de redistribución de datos y conlleva tarifas de bolsa considerablemente más altas. Es el usuario quien lo declara, y es responsable de declararlo con precisión. Si un usuario no está seguro de cuál le corresponde, remítalo a los criterios vigentes de la bolsa en lugar de adivinar, la diferencia de tarifas es real y las reglas cambian.

La solución: firmar el acuerdo y luego asignar

Paso 1: haga que el usuario firme el acuerdo de datos de mercado no profesional

Este es el paso que elimina el error. El acuerdo se presenta dentro de la plataforma Tradovate en la que inicia sesión el usuario, normalmente aparece durante el primer inicio de sesión, en la sección de cuenta o acuerdos, o en el momento en que intenta activar los datos de mercado. El usuario lo revisa, declara el estatus no profesional y acepta. El texto exacto del menú varía entre versiones de la plataforma, así que si está documentando esto para sus propios usuarios, confirme la etiqueta actual en la aplicación en vivo en lugar de fijar una ruta antigua.

Paso 2: agregue la información de contacto del usuario

Antes de que el entitlement se asigne correctamente, el usuario necesita tener registrada su información de contacto. Si omite esto durante el aprovisionamiento, se le pedirá al usuario en su primer inicio de sesión, y hasta que exista, la asignación del entitlement puede estancarse. Complétela como parte de su flujo de configuración para que nada más adelante quede a la espera.

Paso 3: confirme que la firma realmente se sincronizó

Aquí está el matiz. La verificación del entitlement no lee el momento en que el usuario hizo clic en “aceptar”, lee el registro de la cuenta guardado y sincronizado. Dele un momento a la firma para propagarse y vuelva a sincronizar el estado del usuario antes de reintentar. Disparar addEntitlementSubscription en el mismo milisegundo en que el usuario acepta es una forma segura de obtener el mismo error de nuevo por una condición de carrera. Confirme primero que el acuerdo aparece como firmado en los datos sincronizados.

Paso 4: llame a addEntitlementSubscription

Con el acuerdo firmado y sincronizado y la información de contacto en su lugar, asigne el entitlement. Ahora la llamada tiene una cuenta válida y elegible a la cual engancharse, y responde sin problemas. Vuelva a comprobar el cuerpo de la respuesta, un éxito no llevará un errorText. Si está aprovisionando por lotes, marque a un usuario como “listo” solo después de haber verificado el cuerpo, no el código de estado.

Paso 5: verifique que el usuario ahora tenga datos en vivo

Cierre el ciclo confirmando que el usuario realmente ve cotizaciones en tiempo real. Pídale que abra un símbolo del mes cercano y verifique que sea en vivo y no retrasado. Si el entitlement se asignó pero el usuario sigue viendo datos retrasados, puede que también haya que revisar el lado de la suscripción de datos de mercado, el entitlement y una suscripción de datos activa están relacionados pero no son lo mismo, y ambos deben estar correctos para un feed en vivo limpio.

El orden de aprovisionamiento que funciona

Casi todos los tickets de “Live account is required” se deben a ejecutar estas llamadas fuera de orden o a omitir una de ellas. Mantenga la secuencia intacta:

Tabla de solución de problemas

Una nota sobre cuentas prop y de evaluación

Las cuentas de evaluación y simuladas también reciben datos de bolsa en vivo, así que el requisito del acuerdo no desaparece solo porque no haya dinero real en juego. Lo que cambia es la titularidad. Muchas firmas prop gestionan los datos de mercado y los entitlements de forma centralizada como parte de la cuenta que le emiten, en esos casos usted no debería llamar a addEntitlementSubscription en absoluto, y hacerlo puede entrar en conflicto con la forma en que la firma aprovisiona los datos. Las reglas varían según la firma y el tipo de cuenta, así que confirme el proceso actual de su firma antes de aprovisionar entitlements usted mismo. Cuando la firma es dueña del pipeline de datos, la solución ante la falta de datos en vivo es una solicitud de soporte a ellos, no una llamada a la API de su parte.

Evite el forcejeo con los entitlements con PickMyTrade

Si su objetivo es simplemente operar sus señales de TradingView en una cuenta de Tradovate en vivo, no gestionar un pipeline de aprovisionamiento, PickMyTrade se encarga del trabajo técnico del lado del bróker para que usted nunca tenga que tocar llamadas de entitlement:

• Conexión gestionada, el estado del acuerdo de datos y del entitlement de su cuenta se respeta antes de que se envíe cualquier orden, así que no tendrá que depurar un errorText en una respuesta cruda de la API.
• Enrutamiento de alerta a orden, las alertas de TradingView fluyen directamente a su cuenta de Tradovate sin que usted tenga que escribir ni secuenciar llamadas a la API.
• Conciencia de entitlement y riesgo, las órdenes respetan el estado de datos de su cuenta y los límites de la firma prop en lugar de rebotar por un requisito previo faltante.
• Sincronización multicuenta, replique una señal en varias cuentas sin tener que resolver el aprovisionamiento para cada una.