TradingView-Webhook-Bot: Signale sicher in Orders übersetzen

Ein TradingView-Webhook ist eine HTTP-Nachricht, keine garantierte Börsenausführung. TradingView kann die Zustellung abbrechen oder verfehlen; ein laufender Alert verwendet außerdem einen Snapshot des Scripts und seiner Einstellungen. Zwischen Alert und Order braucht es deshalb eine authentifizierte, idempotente und überwachte Ausführungslogik.

Vom Chart zur Order sind es mehrere getrennte Systeme

TradingView erzeugt einen Alert, sobald die konfigurierte Bedingung auslöst. Ist eine Webhook-URL hinterlegt, sendet TradingView einen HTTP-POST an die Empfängeranwendung. Erst diese Anwendung validiert die Nachricht, prüft das Risiko und spricht mit der Exchange-API. TradingView selbst bestätigt damit noch keine echte Order.

1. Pine-Script oder technische Bedingung erzeugt ein Alert-Ereignis.
2. Ein Benutzer erstellt in der Oberfläche einen laufenden Alert.
3. TradingView sendet den Alert an den HTTPS-Endpunkt.
4. Der Empfänger authentifiziert und validiert die Nachricht.
5. Die Strategie- und Risikoregeln entscheiden über Annahme oder Ablehnung.
6. Eine Handelsabsicht wird dauerhaft mit eindeutiger ID gespeichert.
7. Die Exchange nimmt eine Order an, lehnt sie ab oder antwortet nicht eindeutig.
8. Fills und Position werden anschließend mit der Börse abgeglichen.

Der Krypto-Trading-Bot-Leitfaden ordnet die Gesamtarchitektur ein. Die Risikoschicht beschreibt der Artikel Trading-Bot-Risikomanagement.

Offizielle Grenzen von TradingView-Webhooks

TradingView akzeptiert für Webhook-URLs mit explizitem Port nur 80 und 443. Wenn der entfernte Server länger als drei Sekunden für die Verarbeitung benötigt, wird die Anfrage abgebrochen. IPv6 wird laut aktueller Hilfe nicht unterstützt. Webhook-Alerts setzen aktivierte Zwei-Faktor-Authentifizierung voraus.

TradingView weist ausdrücklich darauf hin, dass Webhooks gelegentlich nicht zugestellt werden können. Der Webhook-Status kann im Alert-Log geprüft werden. Der Empfänger sollte deshalb sehr schnell annehmen, die Nachricht dauerhaft in eine Queue schreiben und die eigentliche Börsenverarbeitung asynchron durchführen.

Ein Alert ist ein Snapshot

Beim Erstellen speichert TradingView eine Kopie des Scripts, seiner Inputs, des Symbols und des Zeitrahmens auf seinen Servern. Spätere Änderungen am Chart oder Script ändern einen laufenden Alert nicht. Nach einer Strategieänderung muss der alte Alert gelöscht und im neuen Kontext angelegt werden.

Alerts reagieren nur auf Realtime-Bars. Strategien werden standardmäßig am Schluss einer Bar neu berechnet, sofern das Verhalten nicht bewusst geändert wurde. Zwischen einem Strategie-Order-Fill im Broker-Emulator und einem Live-Fill an der Exchange besteht keine Identität. Backtest und Live-Ausführung müssen getrennt protokolliert werden.

Eine versionierte JSON-Payload statt freiem Text

Ist die Alert-Nachricht gültiges JSON, sendet TradingView den Content-Type application/json; andernfalls text/plain. Ein Produktionssystem sollte ein enges Schema verwenden und unbekannte Felder oder Aktionen ablehnen.

{
 "version": 1,
 "strategy": "breakout-btc-v3",
 "event_id": "{{ticker}}-{{time}}-entry-long",
 "symbol": "BTCUSDT",
 "market": "futures",
 "action": "open_long",
 "signal_time": "{{timenow}}"
}

Positionsgröße und Hebel sollten nicht unbeschränkt aus dem Alert übernommen werden. Der Server berechnet oder begrenzt sie anhand von Konto, Markt und Risk Policy. Zulässige Aktionen wie open_long, close_long oder reduce müssen eindeutig sein; ein unspezifisches sell kann sonst versehentlich eine Short-Position eröffnen.

Authentifizierung ohne Zugangsdaten im Payload

TradingView warnt davor, Login-Daten oder Passwörter in der Webhook-Nachricht zu senden. Der Endpunkt muss HTTPS verwenden. TradingView beschreibt außerdem ein Client-Zertifikat, das bei HTTPS-Anfragen mitgesendet wird und dessen Subject beziehungsweise Subject Alternative Name der Empfänger prüfen kann.

• keine Exchange-API-Keys im Alert oder in der URL;
• Client-Zertifikat nach offizieller TradingView-Dokumentation prüfen;
• zusätzlichen rotierbaren Endpoint-Token verwenden, ohne ihn zu loggen;
• TradingView-IP-Adressen nur ergänzend allowlisten, da Listen geändert werden können;
• Schema, Symbol, Markt, Aktion und Zeitfenster serverseitig validieren;
• Rate Limits pro Strategie und Konto setzen;
• Secrets getrennt vom Webhook-Dienst speichern;
• abgelehnte Payloads mit Grund, aber ohne Secret protokollieren.

Doppelte und verspätete Signale beherrschen

Netzwerk-Retries, mehrfach angelegte Alerts oder Scriptlogik können ähnliche Nachrichten erzeugen. Der Bot braucht deshalb einen fachlichen Idempotenzschlüssel. Derselbe Schlüssel darf innerhalb eines definierten Fensters nur einmal eine Handelsabsicht erzeugen.

Ein Zeitstempel allein reicht nicht immer, und ein Alert-Text darf nicht blind gehasht werden, wenn dynamische Felder enthalten sind. Sinnvoll ist eine Kombination aus Strategieversion, Symbol, Aktion, Bar-Zeit und geplanter Positionsphase. Abgelehnte Duplikate bleiben im Audit-Log sichtbar.

Exchange-Bestätigung entscheidet, nicht der HTTP-Status

Nach Annahme des Webhooks muss der Ausführungsdienst eine eindeutige Client-Order-ID verwenden. Bei einem Exchange-Timeout wird der Orderstatus abgefragt. Erst wenn sicher ist, dass keine Order existiert, darf ein kontrollierter Retry erfolgen. Teilausführungen und Gebühren werden aus Fill-Daten übernommen.

Der Artikel Auto Trading mit Binance behandelt den Exchange-Anschluss. Mit Strategie-Gates lässt sich ein Signal zusätzlich von Session, Marktregime oder Portfolio-Exposure abhängig machen.

Abnahmetest vor Live-Handel

• gültiges und ungültiges JSON senden;
• falsches Zertifikat, Token und Symbol ablehnen;
• identische Payload mehrfach senden;
• Verarbeitung künstlich über drei Sekunden verzögern;
• Exchange-Timeout nach angenommener Order simulieren;
• Teilausführung und Storno testen;
• Script ändern und kontrollieren, dass alter Alert unverändert bleibt;
• Paper/Testnet und kleinen Live-Rollout dokumentieren.

Nach jedem Deployment werden aktive Alert-Versionen, Empfängerstatus und Exchange-Positionen abgeglichen. Ein System darf nicht davon ausgehen, dass ein grüner Webhook-HTTP-Status einen Fill beweist.

Häufige Fragen

Offizielle Quellen

• TradingView: Webhook-Konfiguration, Limits und Zustellstatus
• TradingView: Webhook-Authentifizierung per Zertifikat
• TradingView Pine Script: Alerts, Realtime-Bars und Snapshots
• Binance Developer Docs: API-Authentifizierung und Orderzugriff

Technischer Quellenstand: 2. September 2026. Produktlimits und IP-Listen können sich ändern und sollten vor einem Deployment erneut geprüft werden.

Hinweis: Dieser Artikel dient ausschließlich zur allgemeinen Information und stellt keine Steuerberatung dar. Für individuelle Steuerberatung wende dich an einen zugelassenen Steuerberater.