TradingView-Webhooks an den Broker sicher automatisieren.

Ein TradingView Webhook schickt beim Auslösen eines Alerts eine HTTP-POST-Anfrage an eine von Ihnen festgelegte URL. Damit daraus eine Order beim Broker wird, brauchen Sie einen eigenen Empfänger, der die Nachricht prüft, gegen Risikoregeln abgleicht und erst dann die Broker-API aufruft. Die Technik ist überschaubar, die Tücken liegen in den Details: TradingView bricht Anfragen nach drei Sekunden ab, akzeptiert nur die Ports 80 und 443, unterstützt kein IPv6 und verlangt aktivierte Zwei-Faktor-Authentifizierung. Dazu kommen Duplikate, verlorene Alerts und die Frage, wie sich der Empfänger überhaupt ausweist. Dieser Artikel beschreibt Stand Oktober 2026 eine robuste Architektur, eine Python-Skizze für den Empfänger und eine Checkliste für den ersten Live-Alert. Es geht um Handwerk und Risikokontrolle, nicht um Strategien.

Wie funktionieren TradingView-Webhooks?

Ein Alert in TradingView kann bei Auslösung mehrere Dinge tun: eine Push-Nachricht senden, eine E-Mail verschicken oder eben einen Webhook aufrufen. Beim Webhook schickt TradingView den Text aus dem Feld „Nachricht“ per HTTP-POST an die hinterlegte URL. Ist dieser Text gültiges JSON, setzt TradingView den Header application/json; charset=utf-8, sonst text/plain; charset=utf-8. Für die Automatisierung ist JSON fast immer die bessere Wahl, weil der Empfänger die Felder eindeutig auslesen kann.

Die Nachricht lässt sich mit Platzhaltern füllen, die TradingView beim Auslösen ersetzt. Für Strategie-Alerts aus Pine Script sind vor allem diese relevant: {{strategy.order.action}} (buy oder sell), {{strategy.order.contracts}}, {{strategy.order.id}}, {{strategy.market_position}} sowie {{time}} (Bar-Zeit in UTC) und {{timenow}} (Zeitpunkt der Auslösung). Wie Pine-Strategien selbst aufgebaut sind und wo die Sprache an Grenzen stößt, beschreibt der Artikel zu TradingView Pine Script.

Typisches Beispiel für eine Alert-Nachricht, die ein Empfänger sauber verarbeiten kann:

{
  "token": "<zufälliger Signal-Token, kein Passwort>",
  "strategy": "trend-es-v3",
  "symbol": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "qty": "{{strategy.order.contracts}}",
  "order_id": "{{strategy.order.id}}",
  "position": "{{strategy.market_position}}",
  "bar_time": "{{time}}",
  "fired_at": "{{timenow}}"
}

Ein wichtiger Satz steht in der TradingView-Hilfe selbst: Alerts sind laut TradingView nicht für automatisiertes Trading ausgelegt. Das ist kein Verbot, aber ein klarer Hinweis, dass Zustellung und Latenz nicht garantiert sind. Wer Alerts als Order-Auslöser nutzt, muss die Lücken selbst schließen.

Welche technischen Vorgaben gelten für TradingView-Webhooks?

Die Webhook-Dokumentation von TradingView nennt eine Handvoll harter Vorgaben. Sie entscheiden darüber, wie der Empfänger gebaut sein muss.

Der Timeout ist der Punkt, an dem die meisten Eigenbauten scheitern. Ein naiver Empfänger nimmt den Alert entgegen, verbindet sich mit dem Broker, platziert die Order, wartet auf die Bestätigung und antwortet erst dann. Bei einem langsamen Broker-Gateway oder einer Neuverbindung sind drei Sekunden schnell überschritten. TradingView meldet dann einen Fehler, obwohl die Order womöglich schon ausgeführt wurde. Ob ein Webhook ankam, zeigt das Alert-Log in der Spalte „Webhook status“; TradingView weist selbst darauf hin, dass Webhooks ihr Ziel gelegentlich nicht erreichen.

Welche Architektur braucht ein Webhook-Empfänger?

Bewährt hat sich eine Trennung in vier Stufen. Jede Stufe hat genau eine Aufgabe und lässt sich einzeln testen:

1. Annahme: Ein schlanker HTTP-Endpunkt hinter dem Reverse Proxy prüft Format und Absender, prüft auf Duplikate, legt den Alert in eine Warteschlange und quittiert sofort.
2. Validierung und Risikoprüfung: Ein Worker liest die Warteschlange. Er prüft, ob Symbol und Strategie freigegeben sind, ob die Menge unter dem Limit liegt, ob der Alert nicht zu alt ist, ob ein Not-Aus aktiv ist und ob Tagesverlust- oder Positionsgrenzen erreicht sind.
3. Broker-Adapter: Erst nach bestandener Prüfung wird die Order über die Broker-API gesendet. Bei Interactive Brokers etwa über die TWS API, für die TWS oder IB Gateway laufen muss; bei MetaTrader 5 über das Python-Paket MetaTrader5, das nur unter Windows läuft.
4. Protokoll und Abgleich: Jeder Alert, jede Ablehnung und jede Ausführung wird mit Zeitstempel protokolliert. Ein regelmäßiger Abgleich vergleicht die erwartete Position mit der tatsächlichen Position im Konto.

Der Kern dieser Architektur: TradingView liefert ein Signal, keine Order. Die Entscheidung, ob und in welcher Größe gehandelt wird, trifft Ihr eigener Code nach festen Regeln. So kann ein fehlerhaftes Pine-Skript oder ein falsch konfigurierter Alert nie direkt eine beliebig große Order auslösen.

Eine Python-Skizze für Annahme, Prüfung und Worker mit FastAPI zeigt das Prinzip. Die Funktionen place_order und alarm stehen für Ihren Broker-Adapter und Ihren Benachrichtigungskanal:

# Skizze zur Veranschaulichung, kein produktionsreifer Code
import hmac, json, os, queue, threading, time
from datetime import datetime
from fastapi import FastAPI, Request, Response

app = FastAPI()
SIGNAL_TOKEN = os.environ["SIGNAL_TOKEN"]   # kein Broker-Zugang
MAX_QTY = {"ES1!": 2, "NQ1!": 1}            # Allowlist: Symbol -> max. Menge
seen = set()                                # in Produktion: Datenbank mit Unique-Key
jobs = queue.Queue()

@app.post("/tv-alert")
async def tv_alert(request: Request):
    try:
        msg = json.loads(await request.body())
    except ValueError:
        return Response(status_code=400)
    if not hmac.compare_digest(str(msg.get("token", "")), SIGNAL_TOKEN):
        return Response(status_code=403)
    key = f'{msg.get("strategy")}:{msg.get("order_id")}:{msg.get("bar_time")}'
    if key in seen:
        return Response(status_code=200)    # Duplikat: quittieren, nichts tun
    seen.add(key)
    jobs.put(msg)                           # Arbeit erst nach der Quittung
    return Response(status_code=200)

def risk_ok(msg):
    if os.path.exists("KILL_SWITCH"):       # Not-Aus per Datei
        return False
    limit = MAX_QTY.get(msg.get("symbol"))
    if limit is None or float(msg.get("qty", 0)) > limit:
        return False
    fired = datetime.fromisoformat(msg["fired_at"].replace("Z", "+00:00"))
    return time.time() - fired.timestamp() < 30   # veraltete Alerts verwerfen

def worker():
    while True:
        msg = jobs.get()
        if not risk_ok(msg):
            alarm(f"Alert abgelehnt: {msg.get('strategy')} {msg.get('symbol')}")
            continue
        place_order(msg)    # Broker-Adapter, z. B. TWS API; Ergebnis protokollieren

threading.Thread(target=worker, daemon=True).start()

Die Skizze lässt bewusst vieles weg: dauerhaftes Speichern der Idempotenzschlüssel, Wiederanlauf der Warteschlange nach einem Neustart, Tagesverlustgrenzen und den Positionsabgleich. Für den Dauerbetrieb läuft der Empfänger auf einem Server, der rund um die Uhr erreichbar ist; worauf es dabei ankommt, steht im Beitrag zum VPS-Deployment für Trading-Bots.

Warum gehören keine Zugangsdaten in die Alert-Nachricht?

Eine Webhook-URL ist öffentlich erreichbar. Jeder, der sie kennt, kann Anfragen schicken. Der Empfänger muss deshalb erkennen, ob eine Nachricht wirklich von TradingView stammt. Die naheliegende, aber falsche Lösung ist, Broker-Benutzername, Passwort oder API-Schlüssel in die Alert-Nachricht oder die URL zu schreiben. TradingView rät davon ausdrücklich ab: Sensible Daten wie Zugangsdaten und Passwörter gehören weder in die Webhook-URL noch in die Nachricht.

Die Gründe sind praktisch: Alert-Texte liegen im TradingView-Konto, tauchen in Logs auf, werden beim Kopieren von Alerts mitkopiert und landen im Zweifel in Screenshots. Ein Broker-Schlüssel mit Handelsrechten hat dort nichts verloren. Die Zugangsdaten zum Broker liegen ausschließlich auf Ihrem Server, idealerweise als Umgebungsvariable oder in einem Secret-Speicher, mit den geringsten nötigen Rechten.

Für die Prüfung des Absenders gibt es drei Schichten, die sich ergänzen:

• TLS-Client-Zertifikat: Bei HTTPS sendet TradingView ein Zertifikat mit, ausgestellt auf TradingView, Inc. mit dem Common Name webhook-server@tradingview.com. Ihr Reverse Proxy kann das Zertifikat anfordern und prüfen. Die Konfiguration liegt vollständig auf Ihrer Seite.
• IP-Allowlist (Liste zugelassener Absenderadressen): Nur Anfragen von den vier von TradingView veröffentlichten IPv4-Adressen zulassen. Das ist einfach, aber allein kein Beweis, und die Liste kann sich ändern.
• Signal-Token: Ein zufälliger Wert in der Nachricht, der nur bestätigt, dass der Alert aus Ihrem Konto stammt. Er ist ausdrücklich kein Broker-Zugang, hat für sich allein keine Handelsmacht und wird regelmäßig gewechselt. Er ersetzt die Zertifikatsprüfung nicht, erschwert aber Zufallstreffer.

Entscheidend ist, dass selbst eine gefälschte Nachricht, die alle Prüfungen passiert, nur das auslösen kann, was die Risikoprüfung zulässt: freigegebene Symbole, begrenzte Mengen, keine Order bei aktivem Not-Aus.

Duplikate, Idempotenz und Ausfälle sauber behandeln.

Idempotenz heißt: Dieselbe Nachricht darf beliebig oft ankommen, ausgeführt wird sie genau einmal. Das ist bei Webhooks keine Theorie. Ein Alert kann doppelt angelegt sein, ein Nutzer kann eine Strategie neu laden, oder Ihr Proxy wiederholt eine Anfrage nach einem Netzwerkfehler. Ohne Schutz entsteht dann die doppelte Position. Der Empfänger bildet deshalb aus Strategie-Name, {{strategy.order.id}} und {{time}} einen Schlüssel und speichert ihn dauerhaft, zum Beispiel als eindeutigen Index in einer Datenbank. Kommt derselbe Schlüssel erneut, wird quittiert und nichts getan.

Ebenso wichtig ist das Verhalten bei Fehlern. Die folgende Übersicht zeigt typische Ausfälle und sinnvolle Reaktionen:

Ein Grundsatz für alle Fälle: Im Zweifel lieber keine Order als eine falsche. Ein verpasster Trade kostet eine Chance, eine doppelte oder vertauschte Order mit Hebel kann echtes Geld kosten. Automatisches Wiederholen ist nur sicher, wenn der Code vorher den tatsächlichen Konto- und Orderstatus beim Broker abgefragt hat.

Eigener Empfänger oder Drittanbieter-Bridge?

Neben dem Eigenbau gibt es Dienste, die TradingView-Alerts entgegennehmen und an verschiedene Broker oder Börsen weiterreichen, oft „Bridge“ genannt. Sie sparen Entwicklungszeit, verschieben aber Verantwortung und Risiken. Die Entscheidung hängt weniger an der Technik als an Kontrolle und Vertrauen.

Wer eine Bridge nutzt, sollte prüfen, welche Rechte der hinterlegte Broker-Schlüssel hat (Handel ja, Auszahlung nie), wo der Anbieter sitzt, wie er Zugangsdaten speichert und was bei seinem Ausfall mit offenen Positionen passiert. Ein Hinweis zur Einordnung: Der seit September 2026 als Public Beta verfügbare TradingView-MCP-Server ändert an dieser Frage nichts. MCP (Model Context Protocol) ist ein offener Standard, über den KI-Assistenten auf externe Werkzeuge und Daten zugreifen. Er liefert Marktdaten, Screener, News und Fundamentaldaten und verwaltet Watchlists und einfache Preis-Alerts. Werkzeuge für Broker-Konten, Positionen oder Orderplatzierung führt die Dokumentation nicht auf.

Grenzen und Risiken der Alert-Automatisierung.

Auch eine sauber gebaute Kette bleibt eine Kette aus mehreren Systemen, von denen keines Ihnen gehört. TradingView garantiert die Zustellung nicht, das Netz kann ausfallen, der Broker kann Orders ablehnen oder das Gateway trennen. Die Latenz zwischen Bar-Schluss und Ausführung ist nicht fest und für schnelle Strategien oft zu hoch.

• Signal-Qualität: Eine Pine-Strategie, die im Backtest gut aussieht, kann überangepasst sein oder Werte nutzen, die sich innerhalb einer Bar noch ändern. Alerts, die vor Bar-Schluss feuern, liefern andere Signale als der Backtest.
• Hebel und Totalverlust: Bei Futures, CFDs und gehebelten Krypto-Produkten kann eine Fehlfunktion schnell hohe Verluste verursachen, je nach Produkt und Broker auch über das eingesetzte Kapital hinaus.
• Kontosicherheit: Wer Zugriff auf Ihr TradingView-Konto hat, kann Alerts ändern. 2FA ist deshalb nicht nur Pflicht, sondern Schutz.
• Verantwortung: Für jede ausgeführte Order sind Sie verantwortlich, unabhängig davon, welches System sie ausgelöst hat. Wer Systeme für fremdes Geld betreibt, sollte die aufsichtsrechtliche Einordnung anwaltlich klären lassen.

Für schnelle oder ausführungskritische Strategien ist ein Webhook-Aufbau oft die falsche Wahl. Dann gehört die Logik direkt in ein System, das am Broker hängt, etwa einen Expert Advisor in MetaTrader 5 oder eine Python-Anwendung an der Broker-API, mit TradingView höchstens als Analysewerkzeug.

Checkliste vor dem ersten Live-Alert.

Bevor ein Alert echtes Geld bewegt, sollten diese Punkte erledigt und dokumentiert sein:

1. 2FA im TradingView-Konto aktiv, Broker-Zugang auf minimale Rechte beschränkt, keine Auszahlungsrechte.
2. Empfänger per HTTPS auf Port 443 unter einer IPv4-Adresse erreichbar, Zertifikatsprüfung und IP-Allowlist eingerichtet.
3. Keine Zugangsdaten in Alert-Nachricht oder URL, nur ein wechselbarer Signal-Token.
4. Antwortzeit unter einer Sekunde gemessen, Order-Verarbeitung asynchron.
5. Idempotenzschlüssel dauerhaft gespeichert und mit absichtlich doppelt gesendeten Nachrichten getestet.
6. Risikoregeln aktiv: Symbol-Allowlist, Mengenlimit, Altersprüfung, Tagesverlustgrenze, Not-Aus.
7. Mindestens zwei Wochen im Papier- oder Demokonto mit derselben Kette gelaufen, Abweichungen zwischen Strategie und Konto ausgewertet.
8. Alarmierung bei Ablehnungen, Gateway-Trennung und fehlender Erreichbarkeit getestet.
9. Klares Vorgehen für den Notfall: Wer stoppt den Empfänger, wie werden offene Orders storniert und Positionen geschlossen?

Wenn ich solche Ketten baue, beginne ich mit der Risikoprüfung und dem Logging, nicht mit der Broker-Anbindung. Erst wenn klar ist, was abgelehnt wird und warum, kommt die erste echte Order dazu. Wenn Sie den Aufbau nicht selbst umsetzen wollen, finden Sie unter Trading-Automatisierung den Rahmen, in dem ich solche Systeme entwickle und teste.

Häufige Fragen.

Kann TradingView automatisch Orders bei meinem Broker ausführen?

Nicht direkt über Alerts. Ein Alert kann per Webhook eine Nachricht an eine URL senden. Daraus wird erst eine Order, wenn ein eigener Empfänger oder ein Drittanbieter die Nachricht prüft und die Broker-API aufruft. TradingView weist selbst darauf hin, dass Alerts nicht für automatisiertes Trading ausgelegt sind. Zuverlässigkeit und Risikokontrolle müssen Sie deshalb selbst sicherstellen.

Warum kommt mein TradingView Webhook nicht an?

Häufige Ursachen: Die Zwei-Faktor-Authentifizierung ist nicht aktiv, der Server lauscht auf einem anderen Port als 80 oder 443, der Hostname ist nur per IPv6 erreichbar, oder der Server antwortet nicht innerhalb von drei Sekunden. Den Zustellstatus zeigt das Alert-Log in TradingView. Prüfen Sie außerdem Firewall-Regeln und das TLS-Zertifikat Ihres Servers.

Wie sichere ich einen TradingView Webhook ab?

TradingView sendet bei HTTPS ein TLS-Zertifikat mit dem Common Name webhook-server@tradingview.com mit, das Ihr Server prüfen kann. Ergänzend helfen eine Allowlist der veröffentlichten TradingView-IP-Adressen und ein wechselbarer Signal-Token ohne Handelsrechte. Broker-Zugangsdaten gehören nie in die Nachricht oder die URL, sondern nur auf Ihren Server.

Wie verhindere ich doppelte Orders durch TradingView-Alerts?

Mit Idempotenz: Der Empfänger bildet aus Strategie-Name, Order-ID und Bar-Zeit einen eindeutigen Schlüssel und speichert ihn dauerhaft, etwa als Unique-Index in einer Datenbank. Trifft dieselbe Nachricht erneut ein, wird sie quittiert, aber nicht ausgeführt. Zusätzlich sollte ein regelmäßiger Abgleich die erwartete Position mit dem tatsächlichen Konto vergleichen.

Kann der TradingView-MCP-Server Orders platzieren?

Nein, Stand Oktober 2026 nicht. Der offizielle MCP-Server für KI-Assistenten, seit September 2026 als Public Beta verfügbar, liefert Kursdaten, Screener, Fundamentaldaten und News und kann Watchlists sowie einfache Preis-Alerts verwalten. Werkzeuge für Broker-Konten, Positionen oder Orders führt die Dokumentation nicht auf. Automatisierte Orders aus TradingView-Alerts laufen weiterhin über Webhooks und einen eigenen Empfänger.

Quellen und Stand.

• How to configure webhook alerts — TradingView Help Center
• Webhook authentication — TradingView Help Center
• Using credentials for webhooks — TradingView Help Center
• How to use a variable value in alert — TradingView Help Center
• TradingView MCP server: public beta — TradingView Blog
• TradingView MCP Server documentation — TradingView
• TWS API: Initial Setup — Interactive Brokers
• MetaTrader5 (Python-Paket) — PyPI

Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen TradingView-Alerts sicher mit Ihrem Broker verbinden? Unverbindlich anfragen — wir klären Architektur, Risikoregeln, Testumfang und den Weg in den Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.