Direkt zur Antwort

Telegram Trigger empfängt Updates, der Telegram-Node führt Aktionen aus. Beschränke den Test auf eigene Chat- und Nutzer-IDs und ein eindeutiges Kommando. Pro Bot ist nur ein Webhook registriert; Test und Produktion können sich deshalb gegenseitig verdrängen.

Eingang und Antwort sind zwei verschiedene Schritte

Ein Telegram-Bot ist nicht dein persönliches Telegram-Konto. Er erhält einen eigenen Zugang zur Bot-API. Der Telegram Trigger startet einen n8n-Workflow bei einem passenden Update. Ein nachfolgender Telegram-Node kann beispielsweise eine Nachricht senden.

Unser eigener Lernplan bleibt klein: Ein erlaubter Nutzer schreibt in einem erlaubten privaten Testchat das Kommando /tw-test. Der Ablauf prüft den Eingang und sendet genau einen festen Text zurück. Er öffnet keine Datei, spricht kein KI-Modell an und steuert kein anderes System.

Der Unterschied hilft bei der Fehlersuche. Ein gespeicherter Bot-Zugang belegt noch keinen empfangenen Update. Ein sichtbarer Eingang belegt wiederum nicht, dass eine Antwort an den richtigen Chat geschickt wurde. Prüfe diese Übergänge einzeln.

Ein erlaubter Testeingang wird auf Text und Kommando geprüft und führt zu einer festen Antwort; Test und Produktion erhalten getrennte Bots.
Eigene Ablaufskizze. Kein Produktscreenshot, keine echten Chatdaten und kein ausgeführter Botlauf.

Bot und n8n-Verbindung vorbereiten

Du brauchst ein Telegram-Konto und eine funktionierende n8n-Instanz. Für den Webhookempfang muss Telegram die richtige HTTPS-Adresse erreichen können. Ein nur auf deinem Rechner sichtbares localhost ist keine Adresse, die Telegram aus dem Internet aufrufen kann.

  1. Öffne den offiziellen BotFather in Telegram und starte dort /newbot.
  2. Vergib den sichtbaren Namen und den eindeutigen Bot-Benutzernamen nach den Vorgaben. Die dokumentierten Namen enden auf bot.
  3. Lege in n8n einen passenden Telegram-Zugang an und trage den erhaltenen Wert im Feld Access Token ein.
  4. Wähle diesen Zugang bewusst im Trigger und später im Aktions-Node aus.

Der Zugang gehört weder in einen Prompt noch in eine öffentlich geteilte Workflowbeschreibung. Der Guide Bot-Zugänge in n8n sicher hinterlegen erklärt die Trennung zwischen gespeicherten Zugangsdaten, Node und API-Ziel. Unsere Vorlage enthält kein funktionierendes Token.

Zuerst nur den passenden Eingang prüfen

Erstelle einen neuen Testworkflow mit Telegram Trigger und dem Ereignis Message. Setze Restrict to Chat IDs und Restrict to User IDs passend zu deinem eigenen Test. Die beiden Optionen beantworten unterschiedliche Fragen: Wo darf das Ereignis entstehen und von wem darf es stammen?

Falls du die Kennungen noch nicht kennst, ermittle sie zunächst in einer getrennten Eingangskontrolle ohne nachfolgende Aktionen. Verwende nur deinen eigenen unkritischen Test. Kontrolliere den tatsächlichen Datensatz und trage anschließend die geprüften Kennungen in die Beschränkungen ein, bevor eine Antwortaktion angeschlossen wird.

Message bedeutet nicht automatisch Text. Auch ein Foto oder eine andere Nachricht kann dieses Ereignis auslösen. Ergänze vor der Antwort eine Prüfung auf das erwartete Textfeld und den exakten Inhalt /tw-test. Ein anderer Inhalt bekommt in dieser Probe keine Folgeaktion.

Eigenes Testkommando

/tw-test

Die Oberfläche kann je nach Version etwas anders heißen. Entscheidend bleiben der gewählte Update-Typ, die tatsächlichen IDs und der geprüfte Eingabewert. Wir haben dafür keinen echten Bot eingerichtet oder eine Nachricht verschickt.

Eine feste Antwort bewusst anschließen

Füge nach der erfolgreichen Eingangsprüfung den Telegram-Node hinzu. Wähle Resource: Message und Operation: Send Message. Ordne der Chat ID den geprüften Empfänger aus demselben erlaubten Triggerdatensatz zu. Verwende im Feld Text zunächst ausschließlich:

Eigene feste Testantwort

Tokenwerk-Test empfangen. Keine weiteren Aktionen.

Bevor du dynamische Ausdrücke übernimmst, solltest du Feldpfade in n8n-Expressions nachvollziehen. Eine Kennung aus einem alten Beispiel oder einem anderen Item ist keine bestätigte Empfängeradresse.

Der feste Text vermeidet für diese Probe Probleme mit vom Nutzer gelieferten HTML-/Markdown-Zeichen. Wenn du später dynamische Inhalte sendest, prüfe zusätzlich den gewählten Parse Mode und dessen Formatierungsregeln. Ein Formatierungsfehler ist von einem falschen Zugang oder Empfänger zu unterscheiden.

Den eigenen Telegram-Testplan herunterladen. Er ist ein Feld- und Prüfplan, keine importierbare Workflowdatei und kein Nachweis eines ausgeführten Versands.

Test und Produktion brauchen getrennte Empfangswege

Telegram registriert für einen Bot nur einen Webhook. Wenn n8n zwischen Test- und Produktionsadresse wechselt, wird die registrierte Empfangsadresse überschrieben. Der jeweils andere Weg kann dann keine Updates erhalten. Ein zweiter veröffentlichter Workflow mit demselben Bot ist kein unabhängiger Empfänger.

Verwende für regelmäßige Entwicklung nach Möglichkeit einen separaten Testbot. Das erhält den Produktionsweg während deiner Probe. Ein produktiver Workflow vorübergehend unveröffentlicht zu lassen ist eine andere Möglichkeit, unterbricht aber dessen Empfang bewusst. Der Hintergrundguide „Test- und Produktionswebhooks unterscheiden“ erklärt diese Trennung.

In Gruppen gelten zusätzliche Sichtbarkeits- und Berechtigungsregeln. Schalte nicht pauschal den Privacy Mode aus und mache einen Bot nicht allein für eine Textprobe zum Administrator. Prüfe, welche konkrete Nachricht oder Aktion diese Rechte erfordert. Die private Lernprobe braucht keinen allgemeinen Zugriff auf Gruppengespräche.

Wenn keine Nachricht ankommt

Gehe die Stufen nacheinander durch: Bot-Zugang → Ereignis → registrierter Webhook → HTTPS-Erreichbarkeit → Chat-/User-Beschränkung → Datentyp → Antwortaktion. So vermeidest du einen Modell- oder Serverwechsel, obwohl nur der falsche Empfangsweg aktiv ist.

Fehler nach Stufe eingrenzen
BeobachtungGezielter nächster Check
Funktioniert nur im Test oder nur veröffentlichtWelcher einzelne Webhook ist beim Bot zuletzt registriert worden?
„An HTTPS URL must be provided“Öffentliche Basisadresse und Reverseproxy-Konfiguration prüfen.
Listener wirkt festgefahrenDie n8n-Hilfe nennt insbesondere Websocket-Proxying als möglichen Netzwerkgrund.
Textprobe funktioniert, Foto nichtMessage-Ereignis, tatsächliches Datenfeld und eigenen Textfilter prüfen.
Eingang stimmt, Antwort fehltZugang, Chat-ID, Operation und Textformat der Aktion getrennt ansehen.

Die aktuelle zentrale Endpunktreferenz nennt N8N_WEBHOOK_URL für die Basisadresse. WEBHOOK_URL ist seit n8n 2.35 ein veralteter Alias und erscheint noch in einzelnen Hilfeseiten. Die Variablen N8N_ENDPOINT_* ändern dagegen Pfade. Passe keine produktive Konfiguration nur nach dem Namen einer Fehlermeldung an; prüfe zuerst Version und tatsächlichen Startweg.

Quellen & Methode

Vorgehen und Grenzen

Originalquellen am 20. Oktober 2026 im dokumentierten Umfang geprüft. Vier ausgewählte vollständige Haupttexte pro Thema symmetrisch verglichen. Beispiele und Grafiken sind eigene Lernhilfen. Rechenwerte und simulierte Clientaufrufe sind von echten Produktläufen getrennt; keine Botnachricht, Datenbankinstallation, Anbieterübertragung oder Modellmessung behauptet. Das Smartphone-Cover ist ein erzeugtes Konzept, kein echtes Produktfoto.

Bei Recherche, Texterstellung und Grafiken wird KI eingesetzt. Welche eigenen Versuche vorliegen und was nur als Beispiel dient, beschreibt dieser Beitrag. Unser Redaktionsstandard erklärt die Anforderungen an Belege und Berichtigungen.

Belege für die Aussagen

  1. n8n: TelegramBelegt: Rolle der Aktionen. · geprüft am 20. Oktober 2026
  2. n8n: Telegram TriggerBelegt: Updates und Chat-/Userbeschränkungen. · geprüft am 20. Oktober 2026
  3. n8n: Telegram-ZugangBelegt: BotFather und Access Token. · geprüft am 20. Oktober 2026
  4. n8n: NachrichtenoperationenBelegt: Gelesen: Send Message einschließlich Zusatzfelder; andere Operationsabschnitte nicht als geprüft behauptet. · geprüft am 20. Oktober 2026
  5. n8n: TriggerfehlerBelegt: Ein Webhook, Test/Produktion und HTTPS. · geprüft am 20. Oktober 2026
  6. n8n: EndpunkteBelegt: Aktueller Variablenname und veralteter Alias. · geprüft am 20. Oktober 2026
  7. Telegram: Bot-FAQBelegt: Nachrichtensichtbarkeit und Gruppenkontext; ältere Tokenpfad-/TLS-Beispiele nicht übernommen. · geprüft am 20. Oktober 2026