Webhooks de TradingView a la API de tu bróker
Escribe una estrategia en Pine Script con Claude o ChatGPT, valídala en el Strategy Tester de TradingView y enruta sus alertas mediante un webhook a un entorno de ejecución en la nube que llama directamente a la API REST de tu bróker. Sin terminales de MetaTrader ni VPS de Windows.
Las alertas de TradingView pueden enviar un POST con un cuerpo JSON a cualquier URL HTTPS que controles. TradingHost aloja esa URL en un contenedor siempre activo, procesa la carga útil y envía la orden al bróker. Diseñado para ser compatible con cualquier bróker: brókers de forex y CFD, de acciones y futuros, y exchanges de criptomonedas funcionan de la misma manera, siempre que el bróker ofrezca una API REST o websocket.
Expectativa de latencia: la alerta en el servidor de TradingView se activa aproximadamente entre 1 y 3 segundos después del cierre de la vela; luego, el endpoint REST de tu bróker añade su propia confirmación de orden (normalmente de 100 a 500 ms). El trayecto completo de ida y vuelta tarda unos pocos segundos, no milisegundos. Este flujo de trabajo es adecuado para estrategias de swing trading, posicionales e intradía lentas; no es la opción correcta para scalping, arbitraje de latencia o ejecución en menos de un minuto.
Sección 01 · Cómo encaja todo
Cuatro piezas, un solo ciclo
Todo el flujo de trabajo se basa en cuatro herramientas, cada una con una función específica. TradingView decide cuándo operar. GitHub almacena el código del receptor. TradingHost ejecuta ese código en la nube y aloja la URL del webhook. El bróker ejecuta la orden. Una vez que tienes claro qué hace cada herramienta, el resto de las secciones son detalles que puedes leer por encima.
Tu gráfico y fuente de señales
TradingView
Aloja tu estrategia de Pine Script, ejecuta el Strategy Tester y activa alertas cuando se cumplen las condiciones de entrada o salida. Las alertas pueden enviar un POST con una carga útil JSON a una URL de webhook.
El código de tu receptor
GitHub
Almacena el pequeño servicio receptor que procesa la carga útil de TradingView y llama a la API REST del bróker. Con control de versiones y privado si lo prefieres.
Tu entorno de ejecución en la nube
TradingHost
Obtiene el código del receptor desde GitHub, compila un contenedor y expone una URL de webhook HTTPS estable a la que TradingView puede enviar peticiones POST. Siempre activo. Sin necesidad de mantener tu ordenador encendido.
Tu plataforma de ejecución
API del bróker
Recibe la orden desde tu contenedor de TradingHost a través de la API REST del bróker. Compatible con cualquier bróker: cualquier entidad o exchange con una API REST o websocket documentada funciona exactamente igual.
De cero a una señal en vivo
- Escribe una estrategia en Pine Script en TradingView, utilizando Claude o ChatGPT para programar el código de forma conjunta.
- Realiza un backtest de la estrategia en el Strategy Tester de TradingView antes de plantearte ponerla en producción.
- Haz un fork de una plantilla de receptor de webhooks de TradingHost en tu cuenta de GitHub y personalízala para tu bróker.
- Vincula un entorno de ejecución de TradingHost al repositorio y elige una región; el entorno generará una URL de webhook pública.
- Crea una alerta de TradingView para la estrategia, pega la URL del webhook y configura el cuerpo del mensaje en formato JSON con los marcadores de posición de strategy.order.
- Cuando se activa la alerta, TradingView envía un POST a TradingHost, tu contenedor procesa la carga útil y la llamada a la API de tu bróker ejecuta la orden.
Tiempos del trayecto completo: la alerta en el servidor de TradingView se activa entre 1 y 3 segundos después del cierre de la vela, y el endpoint REST del bróker suele confirmar la orden en un plazo de 100 a 500 ms. En total, hablamos de unos pocos segundos, no de milisegundos. Esto es perfectamente válido para estrategias de swing trading e intradía lentas, pero no es adecuado para scalping o arbitraje de latencia.
Sección 02 · De un vistazo
De un vistazo
- Flujo de trabajo
- Alerta de Pine Script de TradingView a receptor de webhook en la nube y a la API REST del bróker
- Versión de Pine Script
- Pine Script v6 (versión actual del lenguaje de TradingView)
- Transporte de alertas
- POST HTTPS a una URL de webhook proporcionada por el usuario
- Puertos permitidos
- TradingView realiza envíos únicamente a los puertos 80 and 443; se rechazan los demás puertos
- Tiempo de espera de respuesta
- El receptor debe responder en un plazo de tres segundos o la solicitud se cancelará
- Formato del payload
- Cuerpo del mensaje de alerta; se envía como application/json cuando el cuerpo es un JSON válido
- Marcadores de posición de la estrategia
- {{strategy.order.action}}, {{strategy.order.contracts}}, {{ticker}}, {{close}} y similares
- Nivel de plan requerido
- TradingView Plus, Premium o Ultimate (los planes Essential y gratuito no incluyen webhooks)
- Requisitos de la cuenta
- La autenticación de dos factores debe estar habilitada en la cuenta de TradingView
- Entorno de ejecución del receptor
- Servicio contenedorizado siempre activo en TradingHost, desplegado desde GitHub
- Lenguajes
- Cualquier lenguaje que pueda ejecutar un servidor HTTP básico en un contenedor (Python, Node, Go, Rust, etc.)
- Compatibilidad con brokers
- Independiente del broker: cualquier broker o exchange con una API REST o WebSocket documentada (forex, CFD, acciones, futuros, criptomonedas)
- Broker de ejemplo
- Se utiliza la API REST v20 de OANDA como una ilustración breve y sencilla de la llamada del receptor al broker; la página no es específica de OANDA
- Rol de TradingHost
- Entorno de ejecución, despliegue, registros (logs), comprobaciones de estado, selección de región y credenciales de broker cifradas
- Rol de TradingView
- Gráficos, ejecución de Pine Script, generación de alertas y envío de webhooks
- Afiliación
- TradingHost es independiente y no está afiliado a TradingView, PineConnector, OANDA ni a ningún otro servicio mencionado
Sección 03 · Escribir Pine Script con IA
Programe la estrategia en pareja con Claude o ChatGPT
Pine Script es un lenguaje conciso y bien documentado, y la generación actual de modelos de lenguaje grandes ha procesado la referencia pública de Pine Script v6 de TradingView. Describa la estrategia en lenguaje natural en Claude o ChatGPT (o en Cursor utilizando cualquiera de estos modelos): qué monitorizar, qué activa una posición larga, qué activa una posición corta, cómo calcular el tamaño de la orden y cuándo salir. Pegue el código generado en el Editor de Pine de TradingView y deje que el editor detecte cualquier problema de sintaxis.
Debe ser explícito con el modelo en dos aspectos. Primero, pídale un script de estrategia de Pine Script (debe declarar strategy() en lugar de indicator()), ya que solo las estrategias exponen los marcadores de posición {{strategy.order.action}} y {{strategy.order.contracts}} que necesitará en el cuerpo del webhook. Segundo, pídale al modelo que ejecute sus entradas con strategy.entry() y sus salidas con strategy.close(), y que escriba cualquier notificación ad-hoc con la función alert() en lugar de alertcondition(); la función alert() moderna expone los mismos marcadores de posición de la estrategia y acepta un argumento freq que controla si la alerta se activa en cada tick, una vez por barra o una vez al cierre de la barra.
Lea cada línea de código que genere el modelo. El código de trading no perdona los errores sutiles relacionados con el tamaño de las órdenes, el estado de la posición o el comportamiento dentro de la barra. Pida al modelo que le explique cualquier cálculo que no sea obvio antes de aceptarlo. Si busca un flujo de trabajo de IA más integrado en el IDE (Pine junto con un receptor en Python o Go, ambos en el mismo editor), la página del flujo de trabajo de Cursor cubre la parte del IDE de este mismo ciclo.
Sección 04 · Realizar backtesting antes de operar en real
Ejecute el Probador de estrategias antes de conectar el webhook
El Probador de estrategias de TradingView ejecuta su estrategia de Pine Script a lo largo del historial disponible en el gráfico, mostrando el beneficio neto, el factor de beneficio, la detracción (drawdown), el porcentaje de operaciones ganadoras y una lista completa de operaciones simuladas. Las pestañas de Resumen de rendimiento, Lista de operaciones y Propiedades le ofrecen información suficiente para decidir si vale la pena conectar la estrategia a un broker real.
Realice este paso antes de crear cualquier alerta de TradingView con una URL de webhook. Un webhook activo en una estrategia sin validar es la forma más costosa de descubrir un error de programación.
Sección 05 · Alertas y webhooks
Configure la alerta de TradingView y la URL del webhook
Abra el cuadro de diálogo Crear alerta en su gráfico, seleccione la estrategia como condición, vaya a la pestaña Notificaciones y marque la casilla URL del webhook. Pegue el endpoint de webhook de TradingHost como URL. El cuerpo que escriba en el campo Mensaje es lo que TradingView enviará mediante una solicitud POST a esa URL cuando se active la alerta.
Escriba el mensaje en formato JSON. TradingView detecta automáticamente el JSON válido y establece el encabezado Content-Type de la solicitud como application/json, que es lo que espera su receptor. El cuerpo de una alerta de estrategia mínimo contiene el ticker, la dirección (obtenida de {{strategy.order.action}}), el tamaño (obtenido de {{strategy.order.contracts}}) y un secreto compartido que su receptor verifica antes de reenviar cualquier instrucción al broker.
Reglas de transporte documentadas por TradingView
- Método
- HTTP POST. El cuerpo del mensaje de alerta se envía como el cuerpo de la solicitud.
- Puertos
- Únicamente los puertos 80 y 443. Se rechazan las URL de webhook que especifiquen cualquier otro puerto de forma explícita.
- Content-Type
- application/json cuando el cuerpo del mensaje de alerta es un JSON válido. De lo contrario, texto plano.
- Tiempo de espera
- Tres segundos. Si el receptor no responde dentro de ese intervalo, la solicitud se cancela.
- IP de origen
- TradingView publica las direcciones IP de sus webhooks salientes en la pantalla de configuración de alertas. Añádelas a la lista de permitidos en tu cortafuegos o receptor de webhooks.
- Cuenta
- Las alertas por webhook requieren autenticación de dos factores en la cuenta de TradingView.
- Nivel de plan
- Las alertas por webhook están limitadas a los planes Plus, Premium y Ultimate. Los niveles Essential y gratuito no incluyen este método de envío.
Variables para mensajes de alerta
- {{ticker}}
- Símbolo que se muestra en el gráfico en el momento de la alerta.
- {{exchange}}
- Código del exchange, si corresponde.
- {{close}}
- Precio de cierre de la barra que activó la alerta.
- {{volume}}
- Volumen de la barra que activó la alerta.
- {{time}}
- Hora de apertura de la barra en UTC.
- {{strategy.order.action}}
- Devuelve "buy" o "sell" para la orden de la estrategia que se activó. Solo para alertas de estrategia.
- {{strategy.order.contracts}}
- Número de contratos o unidades en la orden ejecutada. Solo para alertas de estrategia.
- {{strategy.order.price}}
- Precio de ejecución reportado por la estrategia. Solo para alertas de estrategia.
- {{strategy.order.id}}
- Identificador que la estrategia asignó a la orden. Solo para alertas de estrategia.
- {{strategy.order.comment}}
- Cadena de comentario opcional que la estrategia adjuntó a la orden.
Un detalle importante de Pine Script: los scripts de tipo indicador pueden activar alertas con alertcondition() o alert(), pero solo los scripts de tipo estrategia exponen las variables {{strategy.*}}. Si quieres que el cuerpo del webhook incluya la dirección y el tamaño de la operación, el script debe declarar strategy() en lugar de indicator().
Sección 06 · Recepción en TradingHost
Aloja la URL del webhook en un entorno de ejecución, no en tu equipo local
La URL del webhook a la que TradingView envía las peticiones debe estar en línea siempre que el mercado esté abierto. Un portátil no es el lugar adecuado; un ordenador de sobremesa con una conexión a internet inestable tampoco; y un VPS de Windows genérico funciona, pero solo si te acuerdas de mantenerlo actualizado y con el terminal correspondiente en ejecución.
TradingHost te ofrece un contenedor Linux basado en Kubernetes que se ejecuta desde un repositorio de GitHub y expone un endpoint HTTPS estable. El código de tu receptor puede ser el que quieras (un controlador FastAPI de Python, una ruta Express de Node, un servidor net/http de Go), siempre que se comunique por HTTP en el puerto 443 y responda dentro del margen de tres segundos de TradingView. Cuando subes código a GitHub, TradingHost reconstruye el contenedor y lo vuelve a desplegar; la URL del webhook no cambia.
Las credenciales de la API del bróker se almacenan como secretos cifrados en el entorno de ejecución, no en tu repositorio de GitHub. El secreto compartido que incluyes en el cuerpo del mensaje de TradingView también se guarda allí. Tu receptor valida el secreto compartido en cada petición entrante, lee las credenciales del bróker desde las variables de entorno y llama a la API del bróker.
Los registros (logs) se transmiten en tiempo real para que puedas ver el flujo en orden: envío de TradingView, procesamiento de la carga útil, envío de la orden y confirmación del bróker. Si algo falla, la línea del registro indica exactamente dónde.
Sección 07 · Ejecución en el bróker
Cualquier bróker con API; la estructura del receptor no cambia
TradingHost es independiente del bróker. Al contenedor de TradingHost no le importa qué bróker esté detrás del endpoint REST al que llama; la estructura del receptor es la misma tanto si el destino es un bróker de forex, de acciones, de futuros o un exchange de criptomonedas. Lo único que varía es el esquema de autenticación, la simbología de los instrumentos y los tipos de órdenes que admite el bróker. Todo lo demás se mantiene igual.
Tipos de brókers compatibles con este flujo de trabajo
- Forex y CFDs
- Brókers con APIs REST estilo v20 y similares (OANDA, IG, Switch Markets y otros en /brokers/forex-and-cfd/).
- Acciones y futuros
- Brókers con pasarelas REST o FIX (Interactive Brokers y otros en /brokers/stocks-and-futures/).
- Exchanges de criptomonedas
- Plataformas de spot y derivados expuestas mediante REST y websocket (Binance, Bybit, OKX, Coinbase, Kraken y más de 60 opciones en /brokers/crypto/, principalmente a través de CCXT).
- Cualquier otro
- Cualquier bróker con una interfaz de órdenes HTTP documentada. El patrón del receptor que se muestra a continuación no cambia.
Qué hace el receptor con cada webhook entrante
- Valida el secreto compartido del cuerpo de la alerta de TradingView antes de reenviar nada.
- Asocia el ticker de TradingView con el código de instrumento del broker (la mayoría de los brokers usan una simbología ligeramente diferente).
- Construye la solicitud de orden con la dirección codificada en el signo del tamaño, un tipo de orden a mercado y el time-in-force recomendado por el broker.
- Envía la solicitud con la cabecera de autenticación del broker (token Bearer, payload firmado con HMAC o OAuth, según el broker).
- Registra la respuesta en los logs, expone los errores y devuelve un 200 OK rápido a TradingView dentro del límite de tiempo de tres segundos.
Un breve ejemplo: OANDA v20
OANDA es un ejemplo práctico de bajo mantenimiento porque su referencia REST v20 está completamente documentada en developer.oanda.com y es fácil abrir cuentas de práctica gratuitas. La estructura: un token de acceso personal Bearer en la cabecera Authorization, un POST a /v3/accounts/{accountID}/orders con el cuerpo de una orden a mercado, dirigido a api-fxtrade.oanda.com para cuentas reales o a api-fxpractice.oanda.com para cuentas de práctica. Este es solo un broker entre muchos; el código del receptor para Interactive Brokers, Binance, OKX o Switch Markets sigue el mismo patrón con el esquema de autenticación y el endpoint de cada broker. Las páginas de /brokers/ detallan las particularidades de cada uno.
Sección 07.5 · Seguridad operativa
Problemas imprevistos cuando hay dinero real en juego
La entrega de alertas de TradingView se realiza bajo el principio de «mejor esfuerzo» (best-effort). Los webhooks pueden perderse, duplicarse o retrasarse. Las API de los brokers pueden devolver reintentos que parecen una orden nueva. Los errores en Pine Script pueden generar tamaños de posición muy alejados del riesgo previsto en la estrategia. El receptor es donde te pones el cinturón de seguridad. A continuación se presentan seis medidas de protección; cada una es un pequeño fragmento de código en el receptor que evita un modo de fallo que el trader no puede solucionar una vez que el sistema está en producción.
01 · Inactividad del receptor
¿Qué pasa si el receptor estaba inactivo cuando se activó una alerta?
TradingView no pone en cola ni reintenta las entregas de webhooks fallidas de forma predeterminada. Si el receptor devuelve una respuesta que no sea 2xx, o tarda más de tres segundos en responder, la alerta se descarta. La estrategia seguirá emitiendo alertas en las siguientes velas, pero la señal perdida no se recuperará. Medida de protección: mantén el receptor lo más simple posible para que siempre responda dentro del límite de tiempo, registra cada payload entrante en el disco antes de procesarlo para que cualquier orden perdida aparezca en los logs del entorno de ejecución, y monitoriza el tiempo de actividad (uptime) para saber si el receptor no estaba disponible cuando se emitió una señal.
02 · Alertas duplicadas
TradingView puede emitir la misma alerta más de una vez
Los valores de Pine Script se actualizan con cada tick dentro de una vela activa. Una llamada a alertcondition o alert configurada en "Every tick" puede activarse varias veces para la misma señal lógica. Incluso con la opción "Once per bar close" activada, los reintentos de TradingView pueden, en ocasiones, entregar el mismo payload dos veces seguidas. Medida de protección: incluye un identificador estable en el cuerpo de la alerta (la hora de la vela, el ID de orden generado por la estrategia o un hash del payload) y rechaza cualquier payload entrante cuyo identificador ya haya sido procesado por el receptor en los últimos minutos. Guarda esa clave de deduplicación en memoria o en un pequeño almacén de clave-valor dentro del entorno de ejecución.
03 · Idempotencia de las órdenes
Diseña cada llamada al broker para que un reintento no cree una posición duplicada
La mayoría de las API REST de los brokers aceptan una clave de idempotencia, que es un ID de orden proporcionado por el cliente que el broker utiliza para deduplicar la misma solicitud en caso de reintento. Configura esto en cada orden que realice el receptor. Usa el mismo identificador que utilizas para la deduplicación de alertas (la hora de la vela o el ID de orden generado por la estrategia) para que el receptor, TradingView y el broker coincidan en qué orden lógica es cada una. Sin esto, un reintento provocado por un fallo de red transitorio puede duplicar la ejecución de la posición.
04 · Límite de tamaño de posición
Limita el tamaño máximo en el que confías de {{strategy.order.contracts}}
El marcador de posición strategy.order.contracts de Pine Script indica el tamaño que la estrategia cree que está operando. Un error en la lógica de la estrategia, un tamaño de posición mal configurado o un bucle infinito pueden generar un valor de contratos mucho mayor de lo que la cuenta puede soportar. Medida de protección: define un tamaño máximo estricto en el receptor, independiente de la estrategia, y rechaza cualquier orden cuyo valor de contratos lo supere. El receptor es la última línea de defensa entre un error de Pine y un ajuste de margen (margin call).
05 · Aislamiento de credenciales
Una clave API con permisos limitados por estrategia, nunca una clave maestra
Si una clave API del broker se ve comprometida debido a un entorno mal configurado, una línea de log filtrada o un artefacto de compilación, el alcance del daño se limita a lo que esa clave pueda hacer. Usa una clave API de broker independiente para cada estrategia, con solo los permisos que esa estrategia necesite (permisos de trading sí, permisos de retiro no), almacénala en el gestor de secretos de TradingHost en lugar de en el código, y rota las claves después de cualquier incidente.
06 · Prueba en demo antes de operar en real
Ejecuta el flujo en una cuenta demo durante una semana antes de aumentar el tamaño
La mayoría de los brokers ofrecen un entorno de simulación (paper trading o sandbox) que acepta las mismas llamadas de API que la cuenta real. Dirige el receptor al sandbox primero, ejecuta la estrategia durante una semana con alertas reales de TradingView y verifica que cada señal se haya convertido en la orden simulada esperada. Operar con dinero real no es el momento adecuado para descubrir que {{strategy.order.action}} codificado como "buy" en lugar de "long" hace fallar tu validación de enums.
Sección 08 · Frente a PineConnector + MT4/MT5
Por qué canalizar un webhook a través de un entorno de ejecución en la nube en lugar de un EA de MetaTrader
La ruta más habitual para enviar una alerta de TradingView a una orden real pasa por PineConnector, un puente de terceros que reenvía las alertas a un Expert Advisor dentro de un terminal de MetaTrader 4 o MetaTrader 5. El EA envía la orden a través de MetaTrader, por lo que el terminal debe permanecer activo en una máquina Windows. TradingHost elimina ese paso por completo: el webhook llega a un contenedor, el contenedor llama directamente a la API REST del broker, y no hay terminal de MetaTrader, ni Expert Advisor de MQL, utilizando GitHub como fuente de verdad y un contenedor Linux que se ejecuta en una región gestionada en lugar de un escritorio Windows que debes mantener encendido.
Comparativa directa
Elija PineConnector si desea específicamente seguir usando MetaTrader, si su bróker solo admite MT o si no quiere escribir nada de código. Elija TradingHost si quiere acceder a la API REST del bróker sin MetaTrader de por medio, prefiere estrategias escritas en un lenguaje de propósito general, quiere usar GitHub como fuente de verdad y desea retirar el VPS de Windows.
Sección 10 · Preguntas frecuentes
Preguntas frecuentes
Sí. TradingView limita las alertas por webhook a los planes Plus, Premium y Ultimate. Los niveles Essential y gratuito no incluyen el método de notificación por URL de webhook.
TradingView envía una petición HTTP POST a la URL de webhook configurada. El cuerpo de la petición es el texto que haya introducido en el campo Mensaje de la alerta. Si ese cuerpo se procesa como un JSON válido, TradingView establece el Content-Type como application/json; de lo contrario, la petición se envía como texto plano.
TradingView no documenta ninguna política de reintentos ni garantía formal de entrega. Las reglas de transporte que sí documenta son: solo puertos 80 y 443, y un margen de respuesta de tres segundos antes de que se cancele la petición. Considere la entrega de webhooks como un servicio de mejor esfuerzo (best-effort) y diseñe su receptor para que sea idempotente.
Puede hacerlo. TradingView publica la lista de direcciones IP de origen desde las que envía los webhooks en la pantalla de configuración de alertas. Algunos receptores rechazan cualquier petición que provenga de fuera de esa lista como una medida de defensa adicional al secreto compartido en el cuerpo del mensaje.
Pine Script v6, la versión actual del lenguaje. TradingView ha indicado que las futuras actualizaciones se aplicarán exclusivamente a la v6.
Solo los scripts de estrategia exponen los marcadores de posición {{strategy.order.action}}, {{strategy.order.contracts}}, {{strategy.order.price}} y similares que utilizará en el cuerpo JSON. Los scripts de indicador pueden seguir activando alertas mediante alert() o alertcondition(), pero sus mensajes de alerta no pueden hacer referencia a los marcadores de posición strategy.*.
alertcondition() es la primitiva original y solo funciona en indicadores; el usuario elige su frecuencia en el cuadro de diálogo Crear alerta. alert() es la función más nueva, funciona en indicadores y estrategias, puede ubicarse en el ámbito local y acepta un argumento freq (alert.freq_all, alert.freq_once_per_bar, alert.freq_once_per_bar_close) directamente en el código.
Para el trading en vivo, es preferible una vez al cierre de la barra. Durante una barra en tiempo real, los valores de Pine pueden actualizarse con cada tick y diferir al cierre de la barra, lo que puede activar una entrada que luego desaparece cuando la barra finaliza. Una vez al cierre de la barra solo se activa cuando esta se confirma.
PineConnector reenvía los webhooks de TradingView a un Expert Advisor de MetaTrader 4 o MetaTrader 5 que se ejecuta dentro de un terminal de MetaTrader. La propia documentación de PineConnector señala que el terminal debe ejecutarse de forma continua, que MetaQuotes VPS no es compatible y que se requiere un VPS de Windows para el alojamiento. TradingHost reemplaza la etapa de MetaTrader con un contenedor Linux que llama directamente a la API REST del bróker. Consulte la comparativa de VPS de Windows para conocer la diferencia en el entorno de ejecución.
Cualquier bróker con una interfaz de órdenes REST o websocket documentada. TradingHost es independiente del bróker: brókers de forex y CFD (OANDA, IG, Switch Markets y otros), brókers de acciones y futuros (Interactive Brokers y otros) e intercambios de criptomonedas (Binance, Bybit, OKX, Coinbase, Kraken y más). Consulte el índice de brókers para ver las plataformas compatibles.
Solo las partes específicas de cada bróker: la cabecera de autenticación (token Bearer, payload firmado con HMAC, OAuth), la simbología de los instrumentos y el vocabulario de tipos de órdenes. La estructura general (validar secreto, mapear ticker, construir orden, enviar, registrar logs) es la misma. Para las plataformas de criptomonedas, CCXT abstrae la mayor parte de estas diferencias.
Secretos encriptados asociados al runtime de TradingHost, no en el repositorio de GitHub. Su receptor los lee del entorno en el momento de la petición. Consulte la página de secretos de la plataforma para conocer el modelo de gestión de credenciales.
TradingView, su bróker y TradingHost se facturan por separado. Los planes de runtime de TradingHost se detallan en precios. Dejará de pagar por un VPS de Windows, un nivel de alojamiento de MetaTrader y una licencia de puente de webhook independiente.