n8n Freelancer

Der Webhook ersetzt das Mail-Skript des Formulars. Das Formular postet direkt auf die n8n-URL, jede Absendung startet eine Ausführung. n8n gibt sofort einen Status 200 zurück und arbeitet den Rest im Hintergrund ab, damit der Absender nicht auf das LLM warten muss.

Beim Test verwendet n8n eine eigene Test-URL, im Betrieb die Production-URL. Ein häufiger Fehler nach dem Livegang: Das Formular zeigt noch auf die Test-URL, die nur läuft, solange der Editor geöffnet ist.

Soll der Nutzer nach dem Absenden auf eine Danke-Seite landen, kommt hinter den Webhook ein "Respond to Webhook"-Node mit einem 303-Redirect. Dann muss der Response-Modus im Webhook auf "Using Respond to Webhook Node" stehen.

Methode

POST

Pfad

/webhook/website-lead

Antwort

sofort, ohne auf den Ablauf zu warten

Aus der PraxisDie Webhook-URL ist öffentlich erreichbar. Rate-Limit pro IP und Honeypot-Feld gehören deshalb in denselben Workflow, nicht in ein vorgelagertes Skript.

Formulare liefern über die Jahre unterschiedliche Feldnamen: message, nachricht, anfrage. Dieser Node bildet alles auf einen festen Satz von Feldern ab. Alle folgenden Nodes greifen nur noch auf diese Namen zu, damit ein neues Formular kein Umbauen im halben Workflow auslöst.

E-Mail-Adressen werden kleingeschrieben und getrimmt. Das verhindert Dubletten im CRM und Treffer, die beim späteren Abgleich gegen bestehende Kunden ins Leere laufen.

Der Zeitstempel wird hier gesetzt und nicht erst beim Versand. Wenn ein späterer Node fehlschlägt und der Workflow erneut läuft, bleibt der Eingangszeitpunkt der echte Eingangszeitpunkt.

Ausgabefelder

name, email, nachricht, quelle, honeypot, eingegangen_am

Modus

Manual Mapping

Drei Bedingungen mit UND-Verknüpfung: Die E-Mail passt auf ein einfaches Muster, die Nachricht hat mindestens 20 Zeichen, das Honeypot-Feld ist leer. Bots füllen unsichtbare Felder aus, echte Absender sehen sie nicht.

Diese Prüfung steht bewusst vor dem LLM. Sie kostet nichts und fängt den größten Teil des automatisierten Spams ab, bevor ein Token verbraucht wird. Umgekehrt würde jede Spam-Mail einen Modellaufruf auslösen.

Die 20 Zeichen sind kein Naturgesetz. Wer ein Formular mit Auswahlfeldern hat, prüft besser auf ausgefüllte Pflichtfelder als auf Textlänge.

Bedingung 1

email entspricht Regex

Bedingung 2

nachricht.length >= 20

Bedingung 3

honeypot ist leer

Aus der PraxisEin Rate-Limit pro IP fehlt in dieser Variante bewusst, weil es je nach Setup unterschiedlich gelöst wird: über einen Reverse Proxy, über n8n-eigene Datentabellen oder über Redis.

Der falsche Zweig endet hier. Der Node tut nichts, aber die Ausführung bleibt im n8n-Log sichtbar. Damit lässt sich nachträglich prüfen, ob die Filter zu streng sind und echte Anfragen aussortiert wurden.

Wer eine Statistik braucht, ersetzt den Node durch einen Append in eine Tabelle oder einen Zähler. Wichtig ist nur, dass der Zweig nicht ins Nichts läuft: Ein offener Ausgang macht in der Ausführungsansicht nicht sichtbar, ob die Bedingung gegriffen hat.

Das Modell bekommt Absender, Quelle und Nachrichtentext und liefert fünf Felder zurück: Kategorie, Dringlichkeit, Thema, Zusammenfassung und Sprache. Es schreibt keine Antwort. Diese Trennung ist der Kern des Workflows: Das Modell entscheidet, welcher Textbaustein passt, aber nicht, was drin steht.

Der Systemprompt definiert die Grenzfälle statt sie offen zu lassen. "Projektanfrage" nur bei erkennbarem Vorhaben, "hoch" nur bei genannter Deadline oder akutem Ausfall. Ohne diese Festlegungen driftet die Einordnung über die Wochen, weil jeder Grenzfall neu geraten wird.

Temperature steht auf 0. Bei einer Klassifizierung ist Varianz kein Feature, sondern der Grund, warum dieselbe Anfrage montags anders behandelt wird als freitags.

Prompt-Typ

Define below

Rückgabe

kategorie, dringlichkeit, thema, zusammenfassung, sprache

Kosten

kleines Modell, deutlich unter einem Cent pro Anfrage

Sub-Nodes hängen unter dem Node, den sie versorgen, und laufen nicht als eigener Schritt in der Kette. Ausgetauscht wird hier das Modell, ohne dass sich am Ablauf etwas ändert.

Für eine Klassifizierung mit fünf Feldern reicht ein kleines Modell. Wer die Daten nicht in die USA geben will, hängt stattdessen ein Modell mit EU-Hosting oder ein lokal betriebenes Modell über Ollama an dieselbe Stelle.

Modell

gpt-4.1-mini (austauschbar)

Temperature

0

Der Parser gibt dem Modell ein Schema vor und prüft die Antwort dagegen. Die Kategorien sind als Enum hinterlegt, das Modell kann also keine vierte Kategorie erfinden, auf die der Switch danach nicht vorbereitet ist.

Ohne Parser landet früher oder später ein Fliesstext oder ein JSON mit Codeblock-Zäunen im nächsten Node, und der Switch fällt in den Standard-Ausgang. Genau dieser Fall fällt im Alltag nicht auf, weil trotzdem eine Mail rausgeht - nur die falsche.

Schema

manuell, mit Enum für kategorie und dringlichkeit

Der Switch liest die Kategorie aus der Modellantwort und schickt die Anfrage in einen der drei Zweige. Der Fallback-Ausgang zeigt auf "Sonstiges", damit auch eine unerwartete Antwort eine Bestätigung auslöst statt still zu enden.

Drei Kategorien sind Absicht. Jede weitere Kategorie braucht einen eigenen Textbaustein, sonst entstehen Zweige, die nie geprüft werden. Erweitern lohnt sich, wenn die Auswertung im Ausführungslog zeigt, dass ein Anliegen regelmäßig unter "Sonstiges" landet.

Ausgang 1

Projektanfrage

Ausgang 2

Support

Ausgang 3

Sonstiges (auch Fallback)

Dieser Zweig hängt am selben Ausgang wie der Switch und läuft parallel. Die Bestätigungsmail wartet also nicht darauf, und eine fehlende Slack-Verbindung verhindert nicht den Versand.

Eskaliert wird nur bei Projektanfrage und Dringlichkeit "hoch". Wer jede Anfrage meldet, hat nach zwei Wochen einen Kanal, den niemand mehr liest. Der Wert der Meldung hängt daran, dass sie selten ist.

Bedingung

kategorie = projektanfrage UND dringlichkeit = hoch

Die Meldung enthält Name, E-Mail, Thema und die Zusammenfassung aus der Klassifizierung. Damit ist im Kanal entscheidbar, wer übernimmt, ohne dass jemand erst das Postfach öffnet.

Slack ist austauschbar. Dieselbe Stelle bedienen Telegram, Microsoft Teams, WhatsApp über die Cloud-API oder schlicht eine zweite Mail an eine interne Adresse.

Ziel

Kanal #leads

Inhalt

Name, E-Mail, Thema, Zusammenfassung

Der Textbaustein liegt als fester Text im Workflow, nicht im Modell. Er nennt einen Zeitrahmen für die persönliche Antwort und bietet einen Terminvorschlag per Rückmail an.

Nur der Vorname wird eingesetzt, aus dem Namensfeld über einen Split am Leerzeichen. Das ist der pragmatische Weg; bei Formularen mit getrennten Feldern für Vor- und Nachname entfällt er.

betreff

Deine Anfrage zu {{ thema }}

antwort

Fester Text mit Vorname und Thema

Bei Support-Fragen fehlen im ersten Kontakt fast immer dieselben Angaben. Der Baustein fragt sie direkt ab: Shop-URL und Screenshot der Fehlermeldung. Das spart eine komplette Runde Rückfrage und Antwort.

Zweck

Fehlende Angaben in derselben Mail nachfordern

Kurz, ohne Versprechen auf eine inhaltliche Antwort. Der Zweig fängt Bewerbungen, Kaltakquise und Nachrichten ab, die sich nicht sicher zuordnen lassen.

Alle drei Textzweige laufen auf diesen einen Node. Betreff und Text kommen aus dem jeweils vorherigen Set-Node, die Empfängeradresse aus dem normalisierten Feld. Ein Versand-Node statt drei bedeutet: eine Stelle für Absenderadresse, Signatur und Fehlerbehandlung.

Versendet wird als reiner Text. Das sieht schlichter aus, kommt aber zuverlässiger an als eine HTML-Mail mit Bildern, und eine automatische Eingangsbestätigung braucht kein Layout.

Gmail ist austauschbar gegen den SMTP-Node, wenn der Versand über das eigene Postfach laufen soll. Wichtig in beiden Fällen: SPF- und DKIM-Einträge der Absenderdomain müssen stimmen, sonst landet die Bestätigung im Spam und der Absender hält die Anfrage für verschwunden.

Empfänger

normalisierte E-Mail aus dem Formular

Format

Text

Attribution

abgeschaltet

Aus der PraxisDie Absenderadresse sollte eine sein, auf die geantwortet werden kann. Eine no-reply-Adresse verschenkt genau die Antworten, wegen denen der Workflow gebaut wurde.

Shopify meldet jede bezahlte Bestellung an n8n. Der Auslöser ist bewusst die Zahlung und nicht der Bestelleingang: Erst dann steht fest, dass es die Bestellung wirklich gibt, und erst dann ist ein Conversion-Wert überhaupt sinnvoll.

Der Trigger liefert die komplette Bestellung samt Positionen, Rabatten und den Zusatzfeldern, die das Theme beim Checkout mitschreibt. Dort stehen auch die Google-Click-ID und der Einwilligungs-Status, deshalb braucht es keinen zweiten Abruf.

Ereignis

Bestellung bezahlt

Liefert

Positionen, Rabatte, Zusatzfelder aus dem Checkout

Zwei Bedingungen müssen zusammen erfüllt sein: Marketing-Einwilligung liegt vor und die Bestellung trägt eine Google-Click-ID. Fehlt eines von beidem, gibt der Node eine leere Liste zurück und die Ausführung endet ohne Zeile in der Tabelle.

Ohne Einwilligung darf keine Bestellung mit einem Klick verknüpft und an Google zurückgemeldet werden. Diese Fälle übernimmt das Modeling im Consent Mode. Eine Zeile zu schreiben und später zu hoffen, dass sie niemand importiert, ist keine Lösung.

Die Click-ID wird beim ersten Seitenaufruf gesetzt und beim Checkout als Zusatzfeld an die Bestellung gehängt. Ohne diesen Schritt im Shop läuft der gesamte Workflow ins Leere, weil sich die Bestellung keinem Klick zuordnen lässt.

Bedingung 1

Marketing-Einwilligung vorhanden

Bedingung 2

Google-Click-ID vorhanden

Sonst

Abbruch ohne Zeile

Aus der PraxisDas Gate steht vor jedem weiteren Abruf. Damit kostet eine Bestellung ohne Einwilligung weder einen Shopify-Call noch eine Zeile in der Tabelle.

Shopify führt je Variante einen Kostenwert im Inventar. Der Node fragt alle Varianten der Bestellung in einem Aufruf ab, statt je Position einen eigenen Request zu schicken.

Fehlt bei einer Variante der Kostenwert, rechnet der nächste Schritt mit einer hinterlegten Fallback-Marge weiter und markiert den Datensatz als geschätzt. Die Alternative wäre, die Bestellung zu verwerfen, und damit würde ausgerechnet der Teil des Sortiments fehlen, der noch nicht sauber gepflegt ist.

Der Node hat Wiederholungen aktiv. Die Shopify-Admin-API antwortet gelegentlich mit einem Rate-Limit, und ein einzelner Fehlversuch soll keine Conversion verschlucken.

Abruf

alle Varianten der Bestellung in einem Aufruf

Bei Fehler

drei Versuche mit Wartezeit

Je Position wird der Bruttoerlös um den gewährten Rabatt gekürzt, über den Mehrwertsteuersatz auf netto gerechnet und um die Stückkosten reduziert. Aus der Summe dieser Positionen zieht der Node noch die Zahlungsgebühr ab, die sich aus einem Prozentsatz und einem Fixbetrag zusammensetzt.

Das Ergebnis ist der Wert, den Google Ads als Conversion-Wert bekommt. Ein Warenkorb mit hohem Umsatz und dünner Marge ist damit weniger wert als ein kleinerer Warenkorb mit gutem Deckungsbeitrag, und genau danach steuert Smart Bidding dann auch.

Negative Werte werden auf null gesetzt. Google Ads nimmt keine negativen Conversion-Werte an, und ein Deckungsbeitrag unter null bedeutet für die Gebotssteuerung ohnehin nur: Diese Bestellung ist nichts wert.

Rechnung

Nettoerlös minus Stückkosten minus Zahlungsgebühr

Ausgabe

Bestellnummer, Anpassungstyp, Wert, Währung, Zeitstempel

Aus der PraxisDie Konstanten für Mehrwertsteuer, Zahlungsgebühr und Fallback-Marge stehen an einer Stelle im Node. Ändert sich der Zahlungsanbieter, ist das eine Zeile und kein Umbau.

Google Ads liest Conversion-Anpassungen über einen geplanten Import aus einer Tabelle. Der Node schreibt genau eine Zeile pro Bestellung in das Vorlagenformat: Bestellnummer, Conversion-Name, Zeitpunkt, Anpassungstyp, Wert und Währung.

Geschrieben wird über Anfügen oder Aktualisieren mit der Bestellnummer als Schlüssel. Läuft dieselbe Bestellung ein zweites Mal durch, wird die vorhandene Zeile überschrieben statt eine zweite angelegt. Das ist wichtig, weil Flow B später denselben Schlüssel noch einmal benutzt.

Der Import in Google Ads läuft zeitgesteuert und nicht sofort. Zwischen Bestellung und korrigiertem Wert im Konto liegen also Stunden, keine Sekunden. Für die Gebotssteuerung reicht das, weil sie ohnehin über Zeiträume lernt.

Modus

anfügen oder aktualisieren

Schlüssel

Bestellnummer

Anpassungstyp

Wert neu festsetzen

Retouren sind ein eigener Flow, weil sie ein eigenes Ereignis sind und Tage oder Wochen nach der Bestellung eintreffen. Der Auslöser meldet nur die Rückgabe selbst, nicht die vollständige Bestellung.

Beide Flows arbeiten unabhängig voneinander und teilen sich keinen Node. Der Kontakt zwischen ihnen läuft allein über die Bestellnummer als Schlüssel in der Importtabelle.

Ereignis

Rückgabe erfasst

Das Retouren-Ereignis enthält nur die zurückgegebenen Positionen. Für den verbleibenden Deckungsbeitrag braucht der Workflow aber die ganze Bestellung: alle ursprünglichen Positionen, alle Rabatte und alle bisherigen Rückgaben.

Deshalb wird die Bestellung neu geladen statt aus dem Ereignis zusammengesetzt. Bei der zweiten Teilretoure einer Bestellung wäre eine Rechnung nur auf Basis des aktuellen Ereignisses falsch, weil die erste Rückgabe darin nicht vorkommt.

Abruf

Bestellung mit allen Rückgaben

Das Consent-Gate wiederholt sich, weil Flow B nicht weiß, ob Flow A für diese Bestellung jemals eine Zeile geschrieben hat. Ohne Einwilligung gab es keine Conversion, und dann gibt es auch nichts zu korrigieren.

Danach summiert der Node alle bisherigen Rückgaben je Position und bildet daraus die Restmenge. Der ursprüngliche Rabatt wird anteilig auf diese Restmenge umgelegt, sonst bliebe der volle Rabatt auf einer kleineren Menge hängen.

Bleibt am Ende keine Position übrig, wird die Bestellung als Vollretoure markiert. Der nächste Schritt schreibt dann keinen neuen Wert, sondern zieht die Conversion komplett zurück.

Gate

Einwilligung und Click-ID wie in Flow A

Berechnet

Restmenge und anteiliger Rabatt je Position

Der Abruf ist derselbe wie in Flow A, nur für die Varianten, die nach der Rückgabe noch beim Kunden sind. Bei einer Vollretoure ist die Liste leer und der nächste Node überspringt die Rechnung.

Die Stückkosten werden erneut gelesen und nicht zwischengespeichert. Eine alte Zahl aus dem Zeitpunkt der Bestellung wäre bequemer, würde aber bei geänderten Einkaufspreisen still falsche Werte liefern.

Bei einer Teilretoure läuft dieselbe Rechnung wie in Flow A, nur auf der Restmenge: Nettoerlös minus Stückkosten minus Zahlungsgebühr. Ergebnis ist der Deckungsbeitrag, der von der Bestellung übrig bleibt.

Bei einer Vollretoure entsteht kein neuer Wert, sondern eine Zeile mit Anpassungstyp Rückzug. Google Ads entfernt die Conversion damit vollständig aus dem Konto, statt sie auf null zu setzen. Der Unterschied zählt: Eine Conversion mit Wert null ist immer noch eine Conversion und verzerrt die Conversion-Rate.

Die Zahlungsgebühr bleibt anteilig stehen, solange noch Umsatz übrig ist. Bei einer Rückerstattung erstattet der Zahlungsanbieter seine Gebühr in der Regel nicht mit.

Teilretoure

Wert neu festsetzen

Vollretoure

Conversion zurückziehen

Der Node schreibt in dieselbe Tabelle wie Flow A und benutzt dieselbe Bestellnummer als Schlüssel. Die Zeile aus der ursprünglichen Bestellung wird dadurch überschrieben, es entsteht keine zweite Zeile zur selben Bestellung.

Google Ads verarbeitet beim nächsten geplanten Import den aktuellen Stand. Eine Bestellung, die vor drei Wochen 40 Euro Deckungsbeitrag wert war und inzwischen halb zurückging, steht dann mit dem korrigierten Wert im Konto.

Aus der PraxisDer Umweg über die Tabelle ist Absicht. Eine Zeile lässt sich ansehen, korrigieren und erneut importieren; ein direkter API-Aufruf gegen Google Ads wäre schneller, aber bei einem Rechenfehler nicht mehr zurückzuholen.

Stripe meldet das Ereignis, sobald eine Zahlung durch ist. Der Auslöser liefert alles, was für die Rechnung gebraucht wird: Name und Anschrift des Kunden, Leistungszeitraum, Beschreibung, Menge, Betrag und Währung.

Bewusst hängt der Workflow an der bezahlten Rechnung und nicht am Zahlungsversuch. Eine fehlgeschlagene Abbuchung soll keine Rechnung in der Buchhaltung erzeugen, die später wieder storniert werden müsste.

Stripe stellt Webhooks mehrfach zu, wenn die Antwort ausbleibt oder zu lange dauert. Genau deshalb steht direkt hinter dem Trigger der Ledger.

Ereignis

Rechnung erfolgreich bezahlt

Liefert

Kundendaten, Positionen, Leistungszeitraum, Betrag

Der Node prüft in einer n8n-Datentabelle, ob zur Stripe-Rechnungsnummer bereits eine Zeile existiert. Gibt es sie, endet die Ausführung hier. Gibt es sie nicht, läuft der Workflow weiter.

Das ist die einzige Stelle, die verhindert, dass aus einer erneut zugestellten Webhook-Meldung eine zweite Rechnung entsteht. Eine Dublette in der Buchhaltung ist deutlich teurer als ein zusätzlicher Prüfschritt: Sie muss storniert werden und taucht bis dahin in jeder Auswertung auf.

Der Schlüssel ist die Stripe-Rechnungsnummer, nicht die Kunden-E-Mail und nicht der Zeitstempel. Nur sie ist je Vorgang eindeutig und bleibt über alle Zustellversuche hinweg gleich.

Prüfung

Zeile zur Stripe-Rechnungsnummer vorhanden

Bei Treffer

Abbruch ohne weitere Aktion

Aus der PraxisDatentabellen gehören zu n8n selbst. Für diese Art Ledger braucht es also keine zusätzliche Datenbank und keinen weiteren Zugang, der gepflegt werden will.

Bevor irgendetwas in Fastbill passiert, schreibt der Workflow eine Zeile mit der Stripe-Rechnungsnummer und dem Status "in Arbeit". Erst danach beginnt die eigentliche Arbeit.

Die Reihenfolge ist der Punkt. Würde der Eintrag erst nach der Rechnung geschrieben, könnten zwei kurz hintereinander zugestellte Zustellversuche beide an der Prüfung vorbeilaufen, weil zu diesem Zeitpunkt noch keine Zeile existiert.

Die Fastbill-Rechnungsnummer bleibt zunächst leer und wird am Ende nachgetragen. Eine Zeile, die dauerhaft auf "in Arbeit" steht, ist damit ein sichtbares Zeichen für einen Abbruch mittendrin.

Geschrieben

Stripe-Rechnungsnummer, Status "in Arbeit"

Ergänzt später

Fastbill-Rechnungsnummer, Endstatus

Fastbill kennt keinen Abgleich über die Stripe-Kundennummer. Gesucht wird deshalb über die E-Mail-Adresse aus der Zahlung, weil sie in beiden Systemen dieselbe ist.

Die Antwort enthält entweder einen Treffer mit Kundennummer oder eine leere Liste. Beides ist ein gültiges Ergebnis, kein Fehler, und beides wird im nächsten Schritt unterschieden.

Bei der Neuanlage wird die Stripe-Kundennummer als Tag am Fastbill-Kunden hinterlegt. Damit bleibt die Verbindung zwischen beiden Systemen nachvollziehbar, auch wenn jemand später die E-Mail-Adresse ändert.

Suche

Fastbill-Kunde über E-Mail-Adresse

Die Bedingung prüft, ob die Trefferliste aus der Suche leer ist. Trifft das zu, führt der wahre Zweig zur Kundenanlage. Andernfalls geht es direkt zur Rechnung für den bestehenden Kunden.

Die Verzweigung ist der Grund, warum es zwei Rechnungs-Nodes gibt: Die Kundennummer kommt im einen Fall aus der Suche, im anderen aus der Antwort der Neuanlage. Inhaltlich ist die Rechnung in beiden Zweigen dieselbe.

wahr

kein Treffer, Kunde wird angelegt

falsch

Kunde existiert, direkt zur Rechnung

Der Node übernimmt Name, Straße, Postleitzahl, Ort, Land und E-Mail-Adresse aus den Stripe-Daten. Der Name wird am ersten Leerzeichen in Vor- und Nachname geteilt, weil Fastbill beides getrennt führt, Stripe aber nur ein Feld liefert.

Fehlt der Nachname, wird der Vorname in beide Felder geschrieben. Das ist unschön, aber die Rechnung entsteht trotzdem. Ein harter Abbruch an dieser Stelle würde bedeuten, dass ein unvollständiger Checkout die Buchhaltung blockiert.

Angelegt wird als Privatkunde. Für Geschäftskunden mit Umsatzsteuer-ID bräuchte es einen eigenen Zweig, der die ID prüft und den Kundentyp anders setzt.

Übernommen

Name, Anschrift, Land, E-Mail-Adresse

Verknüpfung

Stripe-Kundennummer als Tag

Die Kundennummer kommt aus der Antwort des vorherigen Schritts. Rechnungsdatum, Leistungszeitraum, Beschreibung, Menge und Betrag stammen aus der Stripe-Zahlung.

Der Betrag wird als Bruttowert übergeben, weil Stripe brutto abrechnet. Rechnet man ihn hier auf netto um und lässt Fastbill die Steuer wieder aufschlagen, weichen Rechnung und tatsächlich eingezogener Betrag durch die Rundung gelegentlich um einen Cent ab.

Im Einleitungstext steht die Stripe-Referenz. Damit lässt sich jede Rechnung ohne Umweg über den Ledger der passenden Zahlung zuordnen, auch direkt in der Buchhaltung.

Übernommen

Datum, Leistungszeitraum, Position, Menge, Betrag

Betrag

brutto, Steuersatz auf der Position

Inhaltlich identisch zum anderen Zweig, nur die Kundennummer kommt aus der Suche statt aus der Neuanlage. Beide Zweige laufen anschließend in derselben Prüfung zusammen.

Dass es zwei getrennte Nodes sind, ist eine Folge der Fastbill-API: Sie liefert die Kundennummer in Suche und Anlage an unterschiedlichen Stellen der Antwort. Zusammenlegen ließe sich das über einen vorgeschalteten Set-Node, der die Nummer vereinheitlicht.

Die Fastbill-API antwortet auch im Fehlerfall mit Status 200 und packt das Problem in den Antworttext. Ein Fehlschlag wäre ohne diese Prüfung also unsichtbar: Der Workflow gilt als erfolgreich, die Rechnung fehlt.

Geprüft wird deshalb auf die Rechnungsnummer in der Antwort. Ist sie gesetzt, hat Fastbill die Rechnung angelegt. Fehlt sie, führt der falsche Zweig in den Fehlereintrag.

wahr

Rechnungsnummer vorhanden

falsch

Antwort ohne Rechnungsnummer

Aus der PraxisAPIs, die Fehler mit Status 200 ausliefern, sind häufiger als man denkt. Wer sich auf den HTTP-Status verlässt, merkt den Ausfall erst beim Blick in die Buchhaltung.

Die Zeile aus dem Claim wird über die Stripe-Rechnungsnummer gefunden und aktualisiert: Status auf erledigt, Fastbill-Rechnungsnummer eingetragen.

Damit steht in einer Tabelle, welche Stripe-Zahlung zu welcher Fastbill-Rechnung geführt hat. Das ist die Abstimmung, die sonst am Monatsende von Hand passiert.

Geschrieben

Status erledigt, Fastbill-Rechnungsnummer

Der Fehlerzweig endet nicht im Nichts. Die Ledger-Zeile bekommt den Status Fehler und einen gekürzten Auszug der Antwort, damit später nachvollziehbar ist, woran es lag.

Ein Nebeneffekt ist wichtiger als er aussieht: Die Zeile existiert weiterhin mit der Stripe-Rechnungsnummer. Ein erneuter Zustellversuch von Stripe läuft deshalb nicht in eine zweite Rechnung, sondern wird an der ersten Prüfung gestoppt. Der Fall wird von Hand nachgezogen, nicht automatisch wiederholt.

Für eine Meldung per E-Mail oder Chat reicht ein zusätzlicher Node in diesem Zweig. In dieser Fassung genügt der Status in der Tabelle, weil sie ohnehin regelmäßig angesehen wird.

Geschrieben

Status Fehler, gekürzter Antworttext