Tecnología de trading
Una alerta de TradingView es una notificación, no una prueba de que un bróker haya aceptado una orden. Una configuración automatizada puede incluir una estrategia de TradingView, una alerta en vivo, un webhook HTTPS, un servidor o proveedor de ejecución, una API de corretaje y las comprobaciones de riesgo del bróker. Cada etapa puede funcionar mientras falla la siguiente.
La forma más rápida de diagnosticar una orden que no se ejecutó es encuentra la última etapa cuyo éxito pueda demostrar. No cambies la estrategia, recrees todas las alertas ni desactives los límites de riesgo hasta saber en qué punto falló la cadena.
| Detener | Qué verificar | Qué indica el resultado |
|---|---|---|
| 1. Gráfico/estrategia | ¿Hubo un evento en vivo confirmado en el símbolo y el marco temporal correctos? | Una flecha de prueba histórica por sí sola no demuestra que exista una alerta en vivo. |
| 2. Alerta de TradingView | ¿El registro de alertas muestra que la alerta se activó en ese momento? | Confirma que se ejecutó la alerta configurada en el servidor. |
| 3. Entrega del webhook | ¿Qué muestra el estado del webhook en el registro de alertas? | Distingue los fallos de envío o entrega de los problemas de ejecución posteriores. |
| 4. Receptor/puente | ¿El endpoint registró la recepción, validó el payload e intentó enviar una orden? | Aísla las fallas de datos, autenticación y procesamiento del servidor. |
| 5. Respuesta del corredor | ¿La orden fue aceptada, rechazada, cancelada o nunca enviada? | Distingue el enrutamiento de los problemas de poder de compra, instrumento y reglas de la orden. |
TradingView crea una copia de una estrategia en el servidor cuando creas su alerta. Los cambios posteriores en el gráfico no reescriben esa alerta en ejecución. Si cambiaste ajustes, símbolos, marco temporal, lógica de la estrategia o plantillas de mensajes en el gráfico, la alerta anterior puede seguir usando la captura de configuración previa. Compara los ajustes de la alerta en vivo con tu versión guardada y anota cuándo se creó. Vuelve a crear la alerta de forma deliberada solo después de hayas verificado el reemplazo, en lugar de alterar una configuración que funciona durante el diagnóstico.
Una estrategia también puede calcular una condición al cierre de una vela y, de forma predeterminada, simular que la orden se ejecuta en la siguiente. Esto explica algunas diferencias aparentes de una vela; por sí solo, no demuestra que haya faltado la entrega de un webhook.
Abre el registro de alertas e inspecciona la información del estado del webhook de la alerta. Entre las categorías comunes de fallas se incluyen:
Los webhooks de TradingView envían una solicitud POST al endpoint configurado. Si el mensaje de la alerta se interpreta como JSON, TradingView marca su tipo de contenido como application/json; de lo contrario, envía texto sin formato. Una aplicación receptora que espera JSON puede rechazar una carga de texto sin formato.
Si la entrega figura como exitosa, revisa los registros del puente o de la integración con el bróker para la misma marca de tiempo del evento. Busca el ID de la alerta entrante o un ID de correlación seguro, el símbolo que espera el bróker, el sentido de la orden, la disponibilidad del instrumento y la respuesta de la API del bróker. Recibir un webhook no significa que se haya enviado la orden; el puente podría haberla rechazado antes de enviar algo al siguiente destino.
Nunca incluyas contraseñas, tokens de cuentas o secretos de API directamente en mensajes de webhook, registros públicos o capturas de pantalla. Usa endpoints autenticados y almacenamiento de secretos.
Cuando un bróker recibe una orden, puede rechazarla por el nombre del instrumento, el estado del mercado, el margen, el tamaño de la operación, posiciones desactualizadas, tipos de orden no admitidos o reglas de la cuenta. Lee la respuesta de error real del bróker. No deduzcas la causa solo a partir de una notificación verde de TradingView.
Si la cuenta está en vivo, investiga el problema en un entorno de prueba seguro o con solicitudes de diagnóstico que no ejecuten operaciones siempre que sea posible. Evita repetir a ciegas webhooks de órdenes en vivo: puede crear posiciones duplicadas.
Para cada operación que no se ejecutó, registra: fecha y hora del evento con zona horaria; versión de la estrategia y fecha de creación de la alerta; símbolo y marco temporal; ID del evento de alerta; estado del webhook; recepción y estado en el puente; ID de la orden del bróker o rechazo; y si el problema se repitió. Un registro de diez líneas puede ser más útil que 100 capturas cuando la falla es intermitente.
Explorar TradingView. Divulgación de afiliación: Atlas puede ganar una comisión si te suscribes mediante este enlace, sin costo adicional para ti. La suscripción no garantiza compatibilidad con el bróker ni resultados de trading.
Recursos relacionados de Atlas: Tecnología de trading de TGIM · Quant Engineering · Divulgación de afiliados
Fuentes y lecturas adicionales
