„Unsere Software hat keine Schnittstelle“ – diesen Satz höre ich in Gesprächen mit Betrieben oft, meist als Grund, warum ein Prozess angeblich nicht zu automatisieren sei. In den allermeisten Fällen stimmt er so nicht. „Keine API“ heißt selten „keine Anbindung“, sondern nur: Der bequemste Weg fehlt. Dieser Artikel zeigt Geschäftsführern und den Menschen, die bei ihnen automatisieren, welche Wege es gibt – geordnet von robust und günstig bis zum letzten Mittel.
Was „keine Schnittstelle“ meist wirklich heißt
Wenn ein Betrieb sagt, eine Software habe keine Schnittstelle, meint das fast immer eine von drei Sachen: Der Hersteller bewirbt keine API, die API steckt im teureren Tarif, oder niemand hat bisher nachgesehen. Bevor Sie eine Automatisierung deshalb abschreiben, lohnt es sich, eine Leiter von Anbindungswegen durchzugehen. Ganz oben stehen die stabilen, wartungsarmen Wege über Daten; ganz unten der Roboter, der die Bildschirmmaske bedient. Je weiter oben Sie andocken, desto verlässlicher läuft die Automatisierung – und desto weniger bricht sie beim nächsten Update.
Faustregel für die Anbindung: Docken Sie so nah wie möglich an den Daten an, nicht an der Oberfläche. Ein Weg über Datei, Datenbank oder E-Mail übersteht Updates und Layout-Änderungen; ein Roboter, der Felder anklickt, bricht, sobald sich die Maske verschiebt. Die Bildschirmoberfläche ist der letzte Anbindungsweg, nicht der erste.
Zuerst prüfen: Gibt es doch einen fertigen Baustein?
Bevor Sie basteln, prüfen Sie das Naheliegende. Werkzeuge wie n8n bringen laut Dokumentation hunderte fertige Nodes für einzelne Dienste mit – von CRM über Buchhaltung bis Cloud-Speicher. Manches System, dem Sie „keine API“ unterstellen, hat längst einen fertigen Baustein oder zumindest Webhooks. Ein Blick in die Integrationsliste des Werkzeugs und in die Entwickler-Doku des Herstellers spart Ihnen unter Umständen die gesamte weitere Leiter. Und selbst wenn kein fertiger Node existiert: Hat der Dienst eine dokumentierte REST-Schnittstelle, erreichen Sie ihn mit dem HTTP Request-Node, der laut n8n-Doku jeden Dienst mit REST-API abfragen kann – GET, POST und die übrigen Methoden inklusive Authentifizierung und Pagination.
Der Datei-Weg: Export und Import
Der unterschätzteste Weg. Fast jede Branchensoftware kann Daten als Datei ausgeben – als CSV, Excel-Tabelle oder feste Textdatei, oft per Knopfdruck oder zeitgesteuert. Genau da setzen Sie an: Die Software legt einen Export in einen Ordner oder auf einen (S)FTP-Server, und die Automatisierung liest ihn von dort. In n8n zerlegt der Extract From File-Node laut Doku CSV, XLS, XLSX, ODS, PDF und weitere Formate in strukturierte Daten; der Read/Write Files from Disk-Node holt Dateien von dem Rechner, auf dem n8n läuft, oder schreibt sie dorthin – selbst gehostet jeden erreichbaren Pfad, in der Cloud nur ein festes Verzeichnis. Der FTP-Node überträgt Dateien per FTP oder SFTP. Für den Rückweg gilt dasselbe: Ihre Automatisierung erzeugt eine Importdatei im Format, das die Zielsoftware erwartet. Wie so ein Tabellen-Weg konkret aussieht, habe ich für Google Sheets und Excel beschrieben.
Der Datenbank-Weg: lesen, was die Software speichert
Läuft die Anwendung auf einer eigenen Datenbank – etwa PostgreSQL, MySQL oder MS SQL –, können Sie diese oft direkt abfragen. n8n bringt dafür fertige Datenbank-Nodes mit; der Postgres-Node etwa führt mit der Operation Execute Query beliebige SQL-Abfragen aus und liest so genau die Tabellen, in die die Software schreibt. Beschränken Sie sich dabei auf lesende SELECT-Abfragen und nutzen Sie Query-Parameter statt zusammengebauter Strings – n8n bereinigt die Parameter laut Doku und verhindert damit SQL-Injection.
Zwei Dinge sollten Sie vorher klären. Erstens: Direkt in die Datenbank eines fremden Produkts zu schreiben kann die Gewährleistung berühren und bei einem Update brechen, wenn der Hersteller das Schema ändert – lesen ist deutlich unkritischer als schreiben. Zweitens gilt die DSGVO auch hier: Wer direkt auf personenbezogene Daten zugreift, braucht denselben rechtlichen Rahmen wie bei jeder anderen Verarbeitung.
Der E-Mail-Weg: die Schnittstelle, die fast jede Software hat
Was keine API hat, verschickt trotzdem oft E-Mails: Auftragsbestätigungen, Statusmeldungen, Reports als PDF-Anhang. Diese Mails sind eine brauchbare Schnittstelle. Der Email Trigger (IMAP)-Node in n8n verbindet sich mit einem Postfach über IMAP und startet den Workflow, sobald eine neue Nachricht eintrifft; auf Wunsch lädt er die Anhänge gleich mit herunter. Ihre Automatisierung liest dann Betreff, Text oder Anhang aus und zieht die relevanten Daten heraus. Für Posteingänge, die inhaltlich sortiert werden müssen, habe ich das in E-Mail-Triage mit KI vertieft. Der Weg ist nicht elegant, aber erstaunlich stabil – die E-Mail-Vorlage einer Software ändert sich selten.
Die inoffizielle API – nur mit Vorsicht
Viele Web-Anwendungen haben eine interne Schnittstelle, die ihre eigene Oberfläche im Hintergrund bedient, auch wenn der Hersteller sie nicht offiziell anbietet. Über die Entwicklerwerkzeuge des Browsers lässt sie sich beobachten und mit dem HTTP Request-Node nachbauen. Das kann funktionieren – ist aber der wackligste der datenbasierten Wege: Die Schnittstelle ist undokumentiert, kann sich jederzeit ohne Ankündigung ändern, und ihre Nutzung kann den Nutzungsbedingungen des Anbieters widersprechen. Prüfen Sie beides, bevor Sie darauf eine Automatisierung bauen, auf die sich der Betrieb verlässt.
RPA: der Roboter vor dem Bildschirm
Bleibt wirklich nur die Bildschirmmaske – etwa bei alter Terminal-Software oder einer abgeschotteten Citrix-Umgebung –, kommt der letzte Weg: RPA. Ein Roboter bedient die Oberfläche wie ein Mensch, klickt Felder an und tippt Werte ein. Das ist die teuerste und störanfälligste Anbindung, weil jede Layout-Änderung sie brechen kann – aber manchmal die einzige Brücke. Wann sich RPA lohnt und wann die Schnittstelle gewinnt, habe ich in RPA vs. Workflow-Automatisierung gegenübergestellt.
Die Wege im Überblick
| Anbindungsweg | Wann er die erste Wahl ist |
|---|---|
| Fertiger Node oder Webhook | Immer zuerst prüfen – spart den ganzen Rest |
| Offizielle REST-API (HTTP Request) | Dienst hat eine dokumentierte Schnittstelle, aber keinen fertigen Node |
| Datei-Export und -Import | Software kann CSV oder Excel ausgeben oder einlesen |
| Direkter Datenbankzugriff | Sie kennen die Datenbank und dürfen darauf lesen |
| E-Mail über IMAP | Software verschickt Bestätigungen, Reports oder Anhänge |
| RPA / UI-Automation | Nur die Bildschirmmaske ist erreichbar (Legacy, Citrix) |
Was heißt das für Ihre Entscheidung?
„Keine API“ ist selten das Ende, sondern der Anfang der Suche nach dem richtigen Weg. Gehen Sie die Leiter von oben durch: fertiger Baustein, offizielle API, Datei, Datenbank, E-Mail – und erst ganz unten der Roboter. Je höher Sie andocken, desto weniger Wartung kostet die Automatisierung später. Welcher Weg bei Ihrer konkreten Software trägt, lässt sich seriös nur am Einzelfall beurteilen. Genau das mache ich im kostenlosen Prozess-Check: Sie nennen mir die Software, um die es geht, und ich sage Ihnen offen, über welchen Weg sie sich anbinden lässt – oder ob es sich nicht lohnt. Welche Werkzeuge dafür in Frage kommen, steht in der n8n-Beratung.