HTTP 200 heißt nicht, dass es funktioniert hat
Der Workflow meldet Erfolg, und trotzdem ist nichts passiert. Warum ein grüner Statuscode nichts über das Ergebnis aussagt, und wie wir schreibende Aufrufe absichern.
Der Workflow lief monatelang grün, und trotzdem bekam jeder dritte Kunde keine Bestätigung
Ein Onlinehändler verschickte Auftragsbestätigungen über einen E-Mail-Dienst, angebunden über ein Make-Szenario. Bestellung kommt rein, Workflow ruft die Versand-API, Status 200, Häkchen grün, weiter zur nächsten. Im Dashboard sah das wochenlang makellos aus. Dann häuften sich die Anrufe: "Ich habe nie eine Bestätigung bekommen."
Die API hatte brav 200 geantwortet. Nur stand im Antworttext etwas anderes: "accepted: false, reason: recipient rejected". Der Dienst hatte die Mail angenommen, geprüft und verworfen, weil die Adresse ungültig war oder ein Limit erreicht wurde. Das Szenario hat diesen Text nie gelesen. Es hat den Statuscode gesehen, ihn als Erfolg gewertet und ist weitergezogen.
Das ist keine Ausnahme. Das ist einer der häufigsten stillen Fehler, die ich in fremden Automatisierungen finde.
200 beschreibt die Leitung, nicht das Ergebnis
Ein HTTP-Statuscode sagt aus, ob die Anfrage technisch beim Server ankam und ohne Protokollfehler verarbeitet wurde. Er sagt nichts darüber, ob Ihr eigentliches Anliegen erfüllt wurde. Der Server kann antworten "Ich habe deine Anfrage verstanden und sauber abgearbeitet", und das Ergebnis dieser Abarbeitung lautet trotzdem "habe ich abgelehnt".
Die meisten Entwickler stellen sich Statuscodes binär vor: 2xx ist gut, 4xx und 5xx sind schlecht. In der Praxis ist die Grenze unscharf. Sehr viele APIs verpacken fachliche Fehler in eine 200er-Antwort, weil der Server seine Arbeit aus seiner Sicht ja korrekt erledigt hat. Ob das Ergebnis Ihnen passt, ist eine andere Frage, die im Antworttext steht und nicht im Status.
Wo es besonders oft schiefgeht
Drei Stellen sehe ich immer wieder.
Bei Batch-Endpunkten schicken Sie fünfzig Datensätze auf einmal. Die Antwort ist 200, weil der Server die Liste angenommen hat. Im Text steht dann, dass siebenundvierzig durchliefen und drei abgelehnt wurden. Wer nur den Status prüft, verliert diese drei lautlos.
Bei asynchronen Diensten heißt 200 oder 202 lediglich "in die Warteschlange gelegt". Ob die Aufgabe später erfolgreich lief, erfahren Sie nur über einen separaten Abruf oder einen Callback. Der grüne Haken im Workflow bedeutet hier nur, dass jemand den Auftrag entgegengenommen hat.
Und dann gibt es ältere oder eigenwillig gebaute Schnittstellen, die grundsätzlich 200 zurückgeben, egal was passiert ist, und den echten Status ausschließlich in ein Feld wie "errorCode" schreiben. Für solche APIs ist der HTTP-Status komplett wertlos.
Warum gerade No-Code das verschleiert
In Make, n8n oder Zapier markiert das HTTP-Modul einen Schritt als erfolgreich, sobald irgendein 2xx zurückkommt. Der Antworttext landet als Datenpaket im nächsten Schritt, aber niemand schaut hinein, solange Sie es nicht ausdrücklich anweisen. Der Standardpfad führt also immer geradeaus weiter, auch wenn im Text "rejected" steht.
Genau das macht den Fehler so zäh. Die Oberfläche zeigt eine perfekte Erfolgsquote. Es gibt keine rote Fehlermeldung, keine fehlgeschlagene Ausführung, nichts, was ein Monitoring auslösen würde. Der Workflow lügt nicht, er beantwortet nur eine andere Frage als die, die Sie stellen wollten.
Was wir stattdessen prüfen
Nach jedem schreibenden Aufruf lesen wir den Antworttext, nicht nur den Status. Für jede Schnittstelle legen wir vorher fest, woran sich Erfolg konkret erkennen lässt. Bei dem E-Mail-Dienst war das nicht "Status 200", sondern "accepted ist true". Diese Definition gehört dokumentiert, sonst rät der nächste Mensch wieder.
Danach kommt eine ausdrückliche Verzweigung. Eine 200er-Antwort mit fachlichem Fehler im Text muss in dieselbe Fehlerbehandlung laufen wie eine echte 500. Für die Automatisierung sind beide ein Fehlschlag, nur die Verpackung ist anders.
Bei Batch-Aufrufen zählen wir ab. Wir haben fünfzig Datensätze geschickt, also müssen fünfzig Bestätigungen zurückkommen. Stimmt die Zahl nicht, stoppt der Workflow oder schreibt die Differenz in eine Liste, die ein Mensch ansieht. Eine Antwort, die "drei fehlgeschlagen" sagt, ist nur dann hilfreich, wenn dieser Satz auch jemanden erreicht.
So finden Sie es in einem bestehenden Workflow
Wenn Sie eine laufende Automatisierung haben und wissen wollen, ob dieser Fehler bei Ihnen schlummert, gehen Sie die schreibenden Aufrufe durch und stellen Sie pro Aufruf zwei Fragen. Erstens: Prüfe ich hier irgendetwas außer dem Statuscode? Wenn der nächste Schritt direkt nach dem HTTP-Modul kommt und keine Bedingung auf den Antworttext wirft, lautet die Antwort fast immer nein. Zweitens: Was passiert mit den Daten, wenn dieser Aufruf still ablehnt? Führt das zu einer fehlenden Mail, einem nicht angelegten Datensatz, einer Rechnung, die nie rausgeht?
Nehmen Sie sich dann den Anbieter der API vor und lesen Sie nach, wie er Fehler signalisiert. Manche dokumentieren ausdrücklich, dass fachliche Fehler mit 200 und einem Feld im Text kommen. Genau diese Anbieter sind die gefährlichen, weil ihr Verhalten technisch korrekt und für eine naive Verzweigung unsichtbar ist. Zehn Minuten Lektüre der Fehlerdokumentation sparen hier oft Wochen stiller Datenverluste.
Das Muster dahinter
Verlassen Sie sich nicht auf den Umschlag, lesen Sie den Brief. Der Statuscode sagt Ihnen, dass die Post angekommen ist. Ob darin eine Zusage oder eine Absage steckt, steht im Inhalt.
Diese Fehlerklasse ist deshalb so gefährlich, weil sie sich exakt wie Erfolg anfühlt. Keine Warnung, keine Wiederholung, keine Spur in den Protokollen. Sie merken es nicht an der Automatisierung. Sie merken es am Kunden, der drei Wochen später anruft und fragt, warum er nie etwas gehört hat.