FlowTrix Showcase · n8n-Automatisierung
Einmal die Verbindung bauen.
Überall benutzen.
Drei wiederverwendbare n8n-Sub-Workflows bilden das technische Fundament aller FlowTrix-Automatisierungen rund um Lexware Office: einer für die Lexware-API, einer für Nachrichten, einer für Termine. Zugangsdaten, Rate-Limits und Kanal-Logik stehen genau einmal — nicht in jedem Workflow neu.
Ausgangslage
Das Problem
Ohne Bausteine wiederholt jeder Workflow dieselbe Technik: Base-URL, API-Schlüssel, Warte-Logik für das Rate-Limit, Wiederholung bei Fehlern, Bot-Token für Benachrichtigungen. Zwanzig Workflows bedeuten dann zwanzig Stellen, an denen dasselbe steht.
Zugangsdaten mehrfach
Derselbe API-Schlüssel, derselbe Bot-Token, dieselbe Kalender-Anmeldung — an vielen Stellen verstreut.
Uneinheitliche Fehler
Jeder Workflow behandelt Rate-Limits und Fehlerantworten anders. Was bei einem sauber abgefangen wird, bricht beim nächsten ab.
Langsamer Neubau
Jeder neue Workflow beginnt wieder bei der Verbindung, statt direkt mit der eigentlichen Fachlogik zu starten.
Der neue Aufbau
Die Lösung
Die Verbindung wandert in eigene Sub-Workflows — die Bausteine. Ein Fachworkflow ruft einen Baustein mit wenigen Feldern auf und bekommt eine Antwort in immer gleicher Form zurück. Ändert sich ein Zugang, wird er einmal im Baustein geändert.
Die drei Bausteine
Was jeder Baustein übernimmt
Lexware-API-Baustein
Nimmt method, path, query und body entgegen und liefert
statusCode, data, error und retriesUsed zurück.
Base-URL, Header-Auth, Rate-Limit und Wiederholung bei HTTP 429 stecken darin — 10 Nodes.
Messenger-Baustein
Nimmt kanal, ziel und text entgegen und versendet über Telegram,
WhatsApp oder Threema. Die Zugänge liegen ausschließlich hier — 10 Nodes.
Kalender-Baustein
Sucht über aktion: freibusy einen freien Slot in einer Kalender-Gruppe oder legt mit
aktion: anlegen einen Termin an. Backends: Google, Microsoft 365, CalDAV — 18 Nodes.
Rate-Limit ohne Nachdenken
Vor jedem Lexware-Aufruf wartet der Baustein 550 ms. Das Limit von zwei Anfragen pro Sekunde wird auch dann eingehalten, wenn mehrere Workflows kurz hintereinander zugreifen.
EinsatzbereitAutomatischer Retry bei 429
Antwortet die API mit „zu viele Anfragen“, zählt der Baustein den Versuch, wartet 1,2 s und ruft erneut auf — bis zu fünfmal. Danach wird der Fehler sauber zurückgegeben statt endlos zu wiederholen.
EinsatzbereitDokumentation im Workflow
Jeder Baustein enthält eine Notiz-Kachel, die Eingabefelder, Rückgabewerte und die einmalige Einrichtung direkt in n8n erklärt — die Doku liegt dort, wo gearbeitet wird.
EnthaltenBlick hinein
So arbeitet der Lexware-API-Baustein
- Eine Konfiguration: Base-URL
api.lexware.io/v1, Mindestabstand 550 ms, maximal fünf Wiederholungen, 1,2 s Wartezeit vor jedem Versuch. - Kein harter Abbruch: der HTTP-Aufruf liefert auch bei 4xx und 5xx eine Antwort zurück, statt den Workflow zu beenden — so bleibt die Fehlerbehandlung in einer Hand.
- Retry nur wo sinnvoll: wiederholt wird ausschließlich bei HTTP 429. Andere Fehler wie 401 oder 404 gehen sofort mit Klartext an den Aufrufer zurück.
- Nachvollziehbar:
retriesUsedzeigt, wie oft wiederholt werden musste — praktisch, um Lastspitzen zu erkennen.
Schnittstellen
Was ein Workflow übergibt — und zurückbekommt
Jeder Baustein hat einen festen, kleinen Vertrag. Mehr muss ein Fachworkflow nicht wissen.
Lexware-API-Baustein
{ method, path, query, body }
{ statusCode, data, error, retriesUsed }
| Feld | Bedeutung |
|---|---|
method | HTTP-Methode, etwa GET oder POST. Ohne Angabe wird GET verwendet. |
path | Endpunkt hinter der Base-URL, etwa /quotations. Die Version /v1 steckt bereits in der Base-URL. |
query | Objekt mit Query-Parametern. Leere Werte werden verworfen, der Rest wird korrekt kodiert angehängt. |
body | Objekt für den JSON-Body. Bei lesenden Aufrufen leer lassen. |
statusCode | HTTP-Status der Antwort. |
data | Geparster JSON-Body der Antwort. |
error | Fehlertext im Klartext — leer, solange der Status unter 400 liegt. |
retriesUsed | Anzahl der automatischen Wiederholungen nach HTTP 429. |
Messenger-Baustein
{ kanal, ziel, text }
{ ok, kanal, ziel }
| Feld | Bedeutung |
|---|---|
kanal | telegram, whatsapp oder threema. Ohne Angabe greift der Standardkanal aus der Konfiguration. |
ziel | Empfänger: Chat-ID, Telefonnummer oder Threema-ID. Fehlt das Ziel, meldet der Baustein das zurück, statt blind zu senden. |
text | Die Nachricht als Klartext. |
ok | Rückmeldung an den aufrufenden Workflow, zusammen mit gewähltem Kanal und Ziel. |
Kalender-Baustein
{ aktion, kalenderTyp, kalenderIds, dauerMin, fensterVon, fensterBis, titel, beschreibung, terminVon, terminBis }
freibusy → { freiGefunden, slotVon, slotBis, dauerMin }
anlegen → { ok, eventId, link }
| Feld | Bedeutung |
|---|---|
aktion | freibusy sucht einen freien Slot, anlegen trägt einen Termin ein. |
kalenderTyp | google, outlook oder caldav. Ohne Angabe greift der Standardtyp aus der Konfiguration. |
kalenderIds | Die Kalender-Gruppe, deren Frei/Belegt-Zeiten zusammengelegt werden — als Liste oder kommagetrennt. Ohne Angabe wird der Hauptkalender genutzt. |
dauerMin | Benötigte Termindauer in Minuten. Ohne Angabe 60 Minuten. |
fensterVon / fensterBis | Suchzeitraum. Ohne Angabe wird ab morgen für die kommenden 14 Tage gesucht. |
titel / beschreibung | Inhalt des Termins beim Anlegen. |
terminVon / terminBis | Der konkrete Slot, der eingetragen werden soll. |
Typischer Ablauf
So arbeitet ein Fachworkflow mit den Bausteinen
Baustein aufrufen
Der Fachworkflow setzt einen Execute-Workflow-Node und übergibt nur die nötigen Felder — keine Zugangsdaten, keine URL, keine Warte-Logik.
Baustein regelt die Technik
Er ergänzt Base-URL und Anmeldung, hält das Rate-Limit ein, wählt den Messenger-Kanal oder das Kalender-Backend und führt den Aufruf aus.
Zwischenfälle werden abgefangen
Kommt von der Lexware-API ein „zu viele Anfragen“, wartet der Baustein und versucht es erneut. Ein unbekannter Kanal oder Kalendertyp wird mit klarer Meldung gestoppt, statt still ins Leere zu laufen.
Antwort in immer gleicher Form
Der Fachworkflow bekommt ein festes Ergebnis zurück und entscheidet fachlich weiter — er prüft nur noch statusCode beziehungsweise ok.
Anwendungsbeispiel
Ein neuer API-Schlüssel
Ein Betrieb tauscht seinen Lexware-API-Schlüssel aus. Ohne Bausteine müsste jeder Workflow, der Lexware anspricht, einzeln geöffnet und angepasst werden. Mit dem API-Baustein wird das Credential an einer Stelle hinterlegt — alle Fachworkflows nutzen es ab dem nächsten Lauf, ohne dass eine einzige Zeile Fachlogik angefasst wird. Dasselbe gilt, wenn Benachrichtigungen von Telegram auf Threema umgestellt werden: geändert wird der Messenger-Baustein, nicht der Workflow, der die Nachricht auslöst. (Ablauf beispielhaft beschrieben; Aufbau wie in den Workflows umgesetzt.)
Architektur
Aufbau des Systems
api.lexware.io/v1; WhatsApp über die Meta Cloud API, Threema über das Threema Gateway, Telegram über die Bot-API; Kalender über Google Calendar, Microsoft Graph oder CalDAV.Datenschutz & Sicherheit
Sichere Verarbeitung
- Zugangsdaten im Credential-Store: API-Schlüssel und Tokens werden n8n-Credentials zugewiesen und nicht in die Fachworkflows kopiert.
- Kleinere Angriffsfläche: je Dienst gibt es eine einzige Stelle, an der ein Zugang hinterlegt ist — das erleichtert Rotation und Entzug.
- Sparsame Übergabe: Fachworkflows übergeben nur die Felder, die für den Aufruf gebraucht werden.
- Sichtbarer Abbruch: unbekannte Kanäle, unbekannte Kalendertypen und fehlende Empfänger führen zu einer klaren Meldung statt zu stillem Nichtstun.
- Begrenzte Wiederholungen: der 429-Retry ist auf fünf Versuche gedeckelt — keine Endlosschleife gegen einen überlasteten Dienst.
- Selbst gehostet: n8n läuft auf eigener Infrastruktur; ausgehende Verbindungen bestehen nur zu den bewusst eingerichteten Diensten.
Technik-Stack
Womit das gebaut ist
Nutzen & Ergebnis
Was der Betrieb davon hat
Wartung an einer Stelle
Neuer Schlüssel, anderer Kanal, umgestellter Kalender: geändert wird der Baustein — die Fachworkflows bleiben unangetastet.
Einheitliche Fehlerbehandlung
Alle Workflows bekommen Fehler im selben Format. Rate-Limits werden überall gleich behandelt, nicht in jedem Workflow neu erfunden.
Schneller zum nächsten Workflow
Ein neues Projekt startet direkt mit der Fachlogik. Verbindung, Anmeldung und Wartezeiten sind bereits gelöst.
Weniger verstreute Geheimnisse
Zugangsdaten liegen je Dienst an genau einer Stelle statt verteilt über viele Workflows.
Projektstatus
Stand der Umsetzung: einsatzbereit
| Status | Umfang |
|---|---|
| Einsatzbereit | Lexware-API-Baustein — im Einsatz: der Artikel- und Preislisten-Sync greift ausschließlich über diesen Baustein auf die Lexware-API zu und wurde damit gegen die echte API getestet. Rate-Limit, 429-Retry und einheitliche Rückgabe laufen. |
| Gebaut | Messenger-Baustein — vollständig verdrahtet für Telegram, WhatsApp und Threema. Vor dem ersten Versand werden einmalig die Zugänge hinterlegt: Telegram-Credential, WhatsApp-Credential samt Absendernummer, Threema-Gateway-ID und Secret. |
| Gebaut | Kalender-Baustein — Google Calendar und Microsoft 365 sind verdrahtet (Frei/Belegt-Abfrage und Terminanlage); Microsoft 365 setzt eine Azure-App-Registrierung voraus. |
| Vorbereitet | CalDAV / Nextcloud — als Gerüst angelegt und im Ablauf vorgesehen, die eigentliche CalDAV-Abfrage ist noch zu ergänzen. Google und Microsoft 365 stehen bis dahin als Backend bereit. |
| Geplant | Weitere Bausteine nach demselben Muster — etwa für Dateiablagen und E-Mail-Versand — sowie eine gemeinsame Fehler-Benachrichtigung über den Messenger-Baustein. |
Nächster Schritt
Automatisierungen auf ein sauberes Fundament stellen?
FlowTrix baut Automatisierungen zwischen den Systemen, die schon da sind — und trennt dabei Verbindung und Fachlogik von Anfang an.
Kontakt aufnehmen