Encuentra la primera etapa ausente: el evento de alerta de TradingView, la entrega del webhook, el registro del servicio receptor o la respuesta de la orden de Rithmic. Una alerta disparada no es prueba de una ejecución. Conserva las marcas de tiempo y los registros antes de cambiar ajustes o reenviar nada. TradingView documenta reintentos para ciertos errores de servidor HTTP, así que no supongas que un disparo solo puede producir una entrega.
Orientación educativa sobre software. Operar conlleva riesgos. Lea los avisos financieros y de información.
Empieza con la evidencia que tienes
| Última etapa confirmada | Siguiente comprobación útil |
|---|---|
| Señal de estrategia/indicador en el gráfico | ¿Se creó una alerta activa para el evento previsto? |
| Alerta en el Log de TradingView | Configuración de la Webhook URL y Webhook status |
| Resultado de la entrega HTTP | Registro del servicio receptor y validación del payload |
| El servicio aceptó la alerta | Conexión/cuenta previstas y solicitud de orden registrada |
| El bróker confirmó una solicitud | Estado real: activa, rechazada, cancelada o ejecutada |
Si el resultado de una orden es incierto, comprueba el registro de la cuenta/órdenes antes de reenviar la alerta. Un tiempo de espera agotado puede dejar sin conocer el resultado del procesamiento del receptor.
1. Confirma la alerta activa
Comprueba su estado de activación, condición, símbolo, marco temporal y caducidad. En las alertas de scripts, TradingView usa un contexto guardado de script/entradas/gráfico. Cambiar el gráfico o las entradas del script no actualiza esa instantánea existente; vuelve a crear la alerta cuando ese contexto deba cambiar, siguiendo la documentación de alertas de TradingView.
Haz coincidir el evento con la integración: una condición de indicador, una llamada a alert() y un evento de ejecución de orden de estrategia son fuentes distintas. Seleccionar ambos flujos de eventos puede enviar dos solicitudes solo si ambos se disparan realmente y contienen mensajes de operación. Inspecciona la cronología en lugar de suponer duplicación.
2. Inspecciona la entrega del webhook
La guía oficial de configuración de webhooks documenta el campo de notificación, el requisito de autenticación en dos pasos y la columna Webhook status. Usa el endpoint exacto copiado de la aplicación receptora. No adivines una ruta de URL de PickMyTrade.
| Familia de resultado | Qué investigar |
|---|---|
| Redirección | Endpoint modificado o redirección de autorización |
| Error de cliente | Acceso, endpoint, formato o límite de solicitudes |
| Error de servidor | Fallo del servicio receptor y posible reenvío |
| Tiempo de espera agotado/URL no disponible | Tiempo de respuesta, accesibilidad pública y corrección del endpoint |
Son categorías de diagnóstico de la guía de errores de TradingView, no cadenas de error inventadas de PickMyTrade. Una dirección de vista previa localhost no es un endpoint receptor público.
3. Ten en cuenta los reintentos
La guía de reenvío de TradingView indica que las respuestas HTTP 500–599, excepto la 504, pueden provocar reenvíos a intervalos de cinco segundos, con un máximo de cuatro envíos por disparo. No extrapoles esto a todos los tiempos de espera ni a todos los errores. No establece cómo evita el servicio receptor las órdenes duplicadas.
4. Comprueba por separado el receptor y Rithmic
Para PickMyTrade, usa su mensaje actual generado específico de la cuenta. Compara el tipo de señal, la conexión/cuenta, el contrato, la cantidad y el modo de salida. Su referencia JSON publicada usa data y quantity; sustituirlas por action y qty supuestos no es una reparación verificada. La referencia no sustituye al generador actual ni a un payload probado.
Conserva cualquier error de validación del servicio y la respuesta del bróker. Confirma el contrato y la cuenta resueltos antes de interpretar el “éxito”. La cotización nativa capturada aquí muestra datos de ESZ6, no el resultado de un webhook:
Si falta el registro del servicio a pesar de una entrega notificada, proporciona la marca de tiempo/zona horaria y el contexto redactado de la solicitud a través del soporte oficial. No publiques tokens, contraseñas ni ID privados de cuentas u órdenes.
Preguntas frecuentes
¿Significa un HTTP correcto que la operación se ejecutó?
No. Verifica por separado la validación del servicio receptor, la confirmación de la orden y la ejecución registrada.
¿TradingView nunca reintenta?
Documenta un reenvío condicional para ciertas respuestas de error de servidor. No deduzcas de esa regla un reintento universal ni una deduplicación por parte del receptor.
¿Debo reenviar una alerta que agotó el tiempo de espera?
Primero concilia los registros del servicio receptor y del bróker. Un segundo envío puede generar otra solicitud cuando se desconoce el resultado anterior.
¿Arreglará cambiar el gráfico una alerta de script existente?
No necesariamente. Su contexto guardado es independiente; vuelve a crearla cuando ese contexto deba cambiar.