Altsysteme ohne API anbinden: Datei, E-Mail und Bildschirm im Vergleich

Ein Altsystem ohne API lässt sich trotzdem automatisieren – nur nicht mit denselben Bausteinen wie eine moderne Software mit REST-Schnittstelle. In der Praxis bleiben drei Wege: die Datei, das E-Mail-Postfach oder die Bedienoberfläche selbst – und n8n deckt die drei technisch sehr unterschiedlich gut ab.

Ein Hinweis vorweg: Die Angaben zu den einzelnen n8n-Nodes geben den Stand der n8n-Dokumentation vom 14. September 2026 wieder. Node-Verhalten ändert sich zwischen Versionen; die Quellen sind unten verlinkt, damit Sie den aktuellen Stand selbst nachschlagen können.

Die drei Wege im Überblick

	Weg 1: Die Datei	Weg 2: Das E-Mail-Postfach	Weg 3: Der Bildschirm
Was Sie automatisieren	Ein- und Ausgabedateien, die das Altsystem ohnehin schreibt oder liest	Nachrichten und Anhänge, die über ein Postfach laufen	Die Bedienoberfläche selbst, Klick für Klick nachgebaut
n8n-Baustein	Local File Trigger für einen lokalen Ordner, FTP-Node für einen FTP-/SFTP-Server	Email Trigger (IMAP) für eingehende, SMTP-Node für ausgehende Post	Kein eigener Node – Community-Node für Browser-Automatisierung
Voraussetzung am Altsystem	Kann Dateien in ein Verzeichnis schreiben oder von dort lesen	Kann E-Mails senden oder empfangen	Läuft in einem Browser – native Windows-Programme erreicht dieser Weg nicht
Grenze	Local File Trigger läuft nicht auf n8n Cloud und ist seit Version 2.0 standardmäßig deaktiviert	Kein strukturiertes Format garantiert, der Inhalt muss geparst werden	Kann bei Oberflächenänderungen brechen, Community-Node erhält vollen Maschinenzugriff
Passt, wenn	Das System exportiert/importiert ohnehin Dateien	Ein Report, eine Bestätigung oder ein Beleg per Mail bereits existiert	Kein anderer Weg offensteht

Die Vorfrage: Wie „ohne API” ist Ihr Altsystem wirklich?

Bevor Sie über Nodes nachdenken, klären Sie eine Sache: Schreibt oder liest das System bereits Dateien – einen nächtlichen Export, eine Importschnittstelle für Stammdaten? Verschickt es E-Mails – einen automatisierten Report, eine Bestellbestätigung? Nur wenn beides ausscheidet, bleibt der Bildschirm als letzter Weg. Diese Prüfung dauert wenige Minuten und entscheidet, ob Ihr Projekt mit einem robusten Weg beginnt oder mit dem fragilsten der drei.

Weg 1: Die Datei als Schnittstelle

Kann Ihr Altsystem Dateien in ein Verzeichnis schreiben oder von dort lesen, ist das der pragmatischste Einstieg. n8n bringt dafür den Local-File-Trigger-Node mit, der laut n8n-Dokumentation eine Ausführung startet, sobald sich im Dateisystem etwas ändert – eine Datei oder ein Ordner wird hinzugefügt, geändert oder gelöscht. Liegen die Dateien nicht lokal, sondern auf einem entfernten Server, übernimmt stattdessen der FTP-Node den Zugriff auf diesen FTP- oder SFTP-Server; zum Hochladen einer Datei kombinieren Sie ihn mit dem Read/Write-Files-Node oder dem HTTP-Request-Node, die die Datei als Datenanhang bereitstellen.

Zwei Einschränkungen gehören zur Planung dazu. Erstens: Der Local File Trigger steht laut n8n-Dokumentation auf n8n Cloud nicht zur Verfügung – dieser Weg läuft praktisch auf eine selbst gehostete n8n-Instanz hinaus. Zweitens: n8n hat den Node seit Version 2.0 „aus Sicherheitsgründen” standardmäßig deaktiviert, weil er in Umgebungen mit nicht vertrauenswürdigen Nutzern ein Risiko darstellen kann – Sie schalten ihn bewusst frei, statt ihn einfach vorzufinden.

Ein realistischer erster Zuschnitt: Ihr Altsystem legt nachts eine Exportdatei in einen Ordner. Der Local File Trigger feuert, n8n liest die Datei, bildet die Felder auf das Zielsystem ab und legt das Ergebnis ab oder verschickt es weiter. Eine Rückfrage in Echtzeit kennt dieser Weg nicht – wie beim DATEV-Dateiweg liefern Sie, Sie fragen nicht ab.

Weg 2: Das E-Mail-Postfach als Schnittstelle

Verschickt oder empfängt Ihr Altsystem bereits E-Mails – einen täglichen Report, eine automatisierte Bestellbestätigung, eine Rechnung als Anhang –, ist das Postfach der zweite Weg. Der Email-Trigger-(IMAP)-Node ruft laut n8n-Dokumentation Nachrichten über einen IMAP-Server ab; Sie legen fest, aus welchem Postfach gelesen wird, ob eine Nachricht nach dem Abruf als gelesen markiert werden soll, und ob Anhänge heruntergeladen werden – letzteres bewusst nur bei Bedarf aktivieren, weil es laut n8n den Verarbeitungsaufwand erhöht. Für den umgekehrten Weg, also E-Mails aus n8n heraus zu verschicken, steht laut n8n-Dokumentation der SMTP-Node bereit.

Die Grenze liegt im Format: Anders als eine API garantiert eine E-Mail keine strukturierten Daten. Der Betreff, der Text oder ein angehängtes PDF müssen erst geparst werden, bevor die Daten nutzbar sind – bei einer eingehenden Rechnung als E-Mail-Anhang stellt sich dieselbe Frage, die wir beim automatisierten Einlesen von E-Rechnungen im Detail behandelt haben: Wie leicht sich der Inhalt extrahieren lässt, hängt am Format des Anhangs, nicht an n8n.

Weg 3: Der Bildschirm – Browser-Automatisierung, keine Desktop-RPA

Bleibt nur die Bedienoberfläche, wird es technisch am voraussetzungsreichsten. Für eine reine Web-Oberfläche ohne Interaktionsschritte reicht oft schon der HTTP-Request-Node zusammen mit dem HTML-Node, der laut n8n-Dokumentation Inhalte einer Webseite über CSS-Selektoren extrahiert – ein einfacher Abruf und Auslesen, kein Klicken.

Braucht es mehrere Schritte – anmelden, ein Formular ausfüllen, einen Button klicken –, hat n8n dafür keinen eigenen Node (Stand 14. September 2026). Diese Lücke füllen Community-Nodes wie n8n-nodes-puppeteer, die laut eigener Paketseite ein Chrome- oder Chromium-Fenster fernsteuern: Seiten navigieren, Formulare ausfüllen, Screenshots erzeugen. Für die Installation gilt derselbe Hinweis, den n8n bereits im Zusammenhang mit DATEV-Community-Nodes macht: Ein Community-Node erhält vollen Zugriff auf die Maschine, auf der n8n läuft, und die Installation aus npm bedeutet unverifizierten Code aus einer öffentlichen Quelle. Auch ein verifizierter Community-Node muss laut n8n zusätzliche Sicherheitsanforderungen erfüllen – zur genauen Zugriffsebene trifft die Dokumentation keine gesonderte Aussage, das prüfen Sie vor dem Einsatz selbst.

Wichtig zur Einordnung: Puppeteer steuert einen Browser, keine native Windows-Anwendung. Läuft Ihr Altsystem als klassisches Desktop-Programm ohne Weboberfläche, endet dieser Weg – dort beginnt die Domäne klassischer RPA-Software, die für genau diesen Fall gebaut ist und mit der n8n an anderer Stelle bereits verglichen wurde. n8n durch RPA-Funktionen zu ersetzen, die es nicht mitbringt, führt in ein Projekt, das an der falschen Stelle Zeit kostet.

Und selbst innerhalb einer Web-Oberfläche gilt: Jede Änderung am HTML, jedes neue Cookie-Banner, jede verschobene Schaltfläche kann den Workflow lautlos brechen, ohne dass n8n selbst einen Fehler wirft. Ein Workflow auf diesem Weg braucht deshalb eine externe Beobachtung von Anfang an – wie Sie n8n-Workflows überwachen, haben wir gesondert beschrieben.

Für den Mittelstand heißt das

Prüfen Sie die drei Wege in dieser Reihenfolge, nicht danach, welcher am schnellsten aussieht: zuerst die Datei, dann das Postfach, zuletzt der Bildschirm. Die ersten beiden bauen auf etwas auf, das Ihr Altsystem bereits kann – ein Export, ein Versand. Der dritte baut gegen eine Oberfläche, die niemand für die Automatisierung entworfen hat, und die sich ändern kann, ohne dass Sie es vorher erfahren.

Wenn am Ende nur der Bildschirm bleibt, prüfen Sie zusätzlich, ob es tatsächlich eine Web-Oberfläche ist oder eine native Desktop-Anwendung. Für Ersteres hat n8n über einen Community-Node einen Weg, für Zweiteres nicht – und dort lohnt sich der Blick auf klassische RPA-Software für genau diesen einen Prozess, statt Ihre gesamte Automatisierung an einer Lücke aufzuhängen, die n8n nicht schließt.

Wenn Sie unsicher sind, welcher der drei Wege für Ihr Altsystem trägt, hilft unser KI-Quick-Check bei der ersten Einordnung.

FAQ

Kann n8n eine Windows-Anwendung wie ein RPA-Tool bedienen?

Nein (Stand 14. September 2026). Einen eigenen n8n-Node für Desktop- oder Bildschirmautomatisierung gibt es nicht. Was es gibt, sind Community-Nodes für Browser-Automatisierung wie n8n-nodes-puppeteer, die laut eigener Paketseite ein Chrome- oder Chromium-Fenster fernsteuern – eine native Windows-Anwendung ohne Weboberfläche erreichen sie damit nicht. Dafür bleibt klassische RPA-Software der richtige Werkzeugkasten.

Brauche ich für den Datei-Weg zwingend Self-Hosting?

Praktisch ja. Der Local File Trigger steht laut n8n-Dokumentation auf n8n Cloud nicht zur Verfügung und ist seit Version 2.0 aus Sicherheitsgründen standardmäßig deaktiviert – Sie aktivieren ihn bewusst auf einer selbst gehosteten Instanz. Für Dateien auf einem FTP- oder SFTP-Server kommt alternativ der FTP-Node infrage.

Wie riskant ist der Community-Node für Browser-Automatisierung?

n8n weist bei Community-Nodes generell darauf hin, dass sie vollen Zugriff auf die Maschine erhalten, auf der n8n läuft, und dass die Installation aus npm unverifizierten Code aus einer öffentlichen Quelle bedeutet. Auch ein verifizierter Community-Node muss laut n8n zusätzliche Sicherheitsanforderungen erfüllen. Prüfen Sie das vor dem Einsatz, besonders wenn der Workflow an sensiblen Daten hängt.

Was, wenn mein Altsystem weder Dateien schreibt noch E-Mails verschickt?

Dann bleibt praktisch nur der Bildschirm-Weg, mit allen genannten Einschränkungen. Prüfen Sie vorher, ob ein Zwischensystem – ein Reporting-Modul, ein Exportfeature, ein Datenbankzugriff – das Problem umgeht, bevor Sie eine Automatisierung gegen eine Oberfläche bauen, die sich jederzeit ändern kann.

Wie hängt das mit der DATEV-Anbindung zusammen?

Dasselbe Muster: Auch bei DATEV gibt es keinen von n8n gebauten Node, sondern mehrere belegbare Wege über Datei, API-Abonnement oder lokale Schnittstelle. Wer beide Artikel zusammen liest, erkennt das wiederkehrende Prinzip – erst prüfen, welche Übergabeform das System schon anbietet, dann automatisieren.