TradingView-Webhooks an deine Broker-API

Abschnitt 01 · Funktionsweise

Vier Teile, ein Kreislauf

Der gesamte Workflow basiert auf vier Tools, die jeweils eine Aufgabe übernehmen. TradingView entscheidet, wann gehandelt wird. GitHub speichert den Code des Receivers. TradingHost führt diesen Code in der Cloud aus und stellt die Webhook-URL bereit. Der Broker führt die Order aus. Sobald du weißt, welches Tool was tut, kannst du die restlichen Abschnitte hier einfach überfliegen.

Abschnitt 02 · Auf einen Blick

Auf einen Blick

Abschnitt 03 · Pine Script mit KI schreiben

Strategien gemeinsam mit Claude oder ChatGPT schreiben

Pine Script ist eine schlanke, gut dokumentierte Sprache. Die aktuelle Generation von Large Language Models hat die öffentliche Pine Script v6-Referenz von TradingView vollständig erfasst. Beschreiben Sie Ihre Strategie in einfachem Englisch in Claude oder ChatGPT (oder in Cursor mit einem dieser Modelle im Hintergrund): was überwacht werden soll, was ein Long- oder Short-Signal auslöst, wie die Positionsgröße bestimmt wird und wann der Ausstieg erfolgt. Kopieren Sie den generierten Code in den Pine Editor von TradingView, um Syntaxfehler direkt vom Editor anzeigen zu lassen.

Weisen Sie das Modell explizit auf zwei Dinge hin. Erstens: Verlangen Sie ein Pine Script-Strategie-Skript (es muss strategy() statt indicator() deklarieren), da nur Strategien die Platzhalter {{strategy.order.action}} und {{strategy.order.contracts}} bereitstellen, die Sie im Webhook-Body benötigen. Zweitens: Bitten Sie das Modell, Einstiege mit strategy.entry() und Ausstiege mit strategy.close() auszulösen sowie Ad-hoc-Benachrichtigungen über die Funktion alert() statt alertcondition() zu schreiben. Die moderne alert()-Funktion bietet dieselben Strategie-Platzhalter und akzeptiert ein freq-Argument, das steuert, ob der Alarm bei jedem Tick, einmal pro Bar oder einmal beim Schließen der Bar ausgelöst wird.

Prüfen Sie jede Zeile, die das Modell schreibt. Trading-Code verzeiht keine subtilen Fehler bei der Positionsgrößenbestimmung, dem Positionsstatus oder dem Verhalten innerhalb einer Bar (Intra-Bar). Lassen Sie sich unklare Berechnungen vom Modell erklären, bevor Sie sie übernehmen. Wenn Sie einen tiefergehenden AI-IDE-Workflow nutzen möchten (Pine und ein Python- oder Go-Receiver in einem gemeinsamen Editor), beschreibt die Cursor-Workflow-Seite die IDE-Seite dieses Prozesses.

Abschnitt 04 · Vor dem Live-Gang backtesten

Führen Sie den Strategy Tester aus, bevor Sie den Webhook verbinden

Der Strategy Tester von TradingView lässt Ihre Pine Script-Strategie über die verfügbare Historie des Charts laufen und liefert Nettogewinn, Profit-Faktor, Drawdown, Gewinnquote sowie eine vollständige Liste der simulierten Trades. Die Tabs „Performance-Zusammenfassung“, „Liste der Trades“ und „Eigenschaften“ bieten Ihnen eine solide Entscheidungsgrundlage, ob es sich lohnt, die Strategie mit einem echten Broker zu verbinden.

Führen Sie diesen Schritt aus, bevor Sie einen TradingView-Alarm mit einer Webhook-URL erstellen. Ein Live-Webhook auf einer ungeprüften Strategie ist der teuerste Weg, um Programmierfehler zu finden.

Abschnitt 05 · Alarme und Webhooks

TradingView-Alarm und Webhook-URL konfigurieren

Öffnen Sie das Dialogfenster „Alarm erstellen“ auf Ihrem Chart, wählen Sie die Strategie als Bedingung aus, wechseln Sie zum Tab „Benachrichtigungen“ und aktivieren Sie „Webhook-URL“. Fügen Sie den TradingHost-Webhook-Endpunkt als URL ein. Der Text, den Sie in das Feld „Nachricht“ eingeben, wird von TradingView per POST-Request an diese URL gesendet, sobald der Alarm ausgelöst wird.

Schreiben Sie die Nachricht als JSON. TradingView erkennt gültiges JSON automatisch und setzt den Content-Type der Anfrage auf application/json – genau das, was Ihr Receiver erwartet. Ein minimaler Payload für einen Strategie-Alarm enthält den Ticker, die Richtung (aus {{strategy.order.action}}), die Größe (aus {{strategy.order.contracts}}) und ein Shared Secret, das Ihr Receiver prüft, bevor er Daten an den Broker weiterleitet.

Abschnitt 06 · Empfang auf TradingHost

Webhook-URL auf einer Runtime hosten, nicht auf dem eigenen Laptop

Die Webhook-URL, an die TradingView sendet, muss immer online sein, wenn die Märkte geöffnet sind. Ein Laptop ist dafür der falsche Ort; ein Desktop-PC mit instabiler Internetverbindung ebenfalls. Ein gewöhnlicher Windows-VPS funktioniert zwar, aber nur solange Sie daran denken, ihn zu patchen und das entsprechende Terminal laufen zu lassen.

TradingHost stellt Ihnen einen Kubernetes-basierten Linux-Container bereit, der direkt aus einem GitHub-Repository läuft und einen stabilen HTTPS-Endpunkt bereitstellt. Ihr Receiver-Code kann völlig frei gestaltet werden (z. B. ein FastAPI-Handler in Python, eine Express-Route in Node oder ein net/http-Server in Go), solange er HTTP auf Port 443 spricht und innerhalb des dreisekündigen Zeitfensters von TradingView antwortet. Wenn Sie Code zu GitHub pushen, baut TradingHost den Container neu und führt das Deployment aus – die Webhook-URL bleibt dabei unverändert.

Die API-Zugangsdaten Ihres Brokers werden als verschlüsselte Secrets auf der Runtime gespeichert, nicht in Ihrem GitHub-Repository. Das Shared Secret, das Sie im Nachrichtentext von TradingView hinterlegen, befindet sich ebenfalls dort. Ihr Receiver validiert dieses Shared Secret bei jeder eingehenden Anfrage, liest dann die Broker-Zugangsdaten aus der Umgebung aus und ruft die Broker-API auf.

Logs werden in Echtzeit gestreamt, sodass Sie die genaue Reihenfolge nachvollziehen können: TradingView-Anfrage empfangen, Payload geparst, Order übermittelt, Broker-Bestätigung erhalten. Falls ein Fehler auftritt, zeigt die Log-Zeile genau an, wo es hakt.

Abschnitt 07 · Ausführung beim Broker

Jeder Broker mit API – die Struktur des Receivers bleibt gleich

TradingHost ist brokerunabhängig. Dem TradingHost-Container ist es egal, welcher Broker hinter dem aufgerufenen REST-Endpunkt steht. Dieselbe Receiver-Struktur funktioniert unabhängig davon, ob das Ziel ein Forex-Broker, ein Aktien-Broker, ein Futures-Broker oder eine Krypto-Börse ist. Die einzigen Unterschiede liegen im Authentifizierungsverfahren, der Symbolik der Handelsinstrumente und den vom Broker unterstützten Ordertypen. Alles andere bleibt gleich.

Abschnitt 07.5 · Betriebssicherheit

Was schiefgehen kann, wenn es um echtes Geld geht

Die Zustellung von TradingView-Alerts erfolgt nach dem Best-Effort-Prinzip. Webhooks können verloren gehen, mehrfach gesendet werden oder sich verzögern. Broker-APIs können bei Wiederholungsversuchen Antworten liefern, die wie eine neue Order aussehen. Fehler in Pine Script können zu Positionsgrößen führen, die weit außerhalb des geplanten Risikos der Strategie liegen. Der Empfänger ist der Ort, an dem Sie den Sicherheitsgurt anlegen. Unten finden Sie sechs Schutzmaßnahmen; jede ist ein kleines Stück Empfänger-Code, das ein Fehlerszenario verhindert, das der Trader nach dem Live-Gang nicht mehr beheben kann.

Abschnitt 08 · Im Vergleich zu PineConnector + MT4/MT5

Warum ein Webhook über eine Cloud-Runtime statt über einen MetaTrader-EA geroutet werden sollte

Der am häufigsten genutzte Weg von einem TradingView-Alert zu einer echten Order führt über PineConnector – eine Bridge von Drittanbietern, die Alerts an einen Expert Advisor innerhalb eines MetaTrader 4- oder MetaTrader 5-Terminals weiterleitet. Der EA übermittelt die Order über MetaTrader, weshalb das Terminal durchgehend auf einem Windows-Rechner laufen muss. TradingHost macht diesen Schritt überflüssig: Der Webhook geht direkt an einen Container, der Container ruft die REST-API des Brokers auf. Es gibt kein MetaTrader-Terminal, keinen MQL Expert Advisor, GitHub dient als Source of Truth und ein Linux-Container läuft in einer verwalteten Region statt auf einem Windows-Desktop, den Sie aktiv halten müssen.