FACHBEITRAG · 24. JANUAR 2026
API-Automatisierung: Warum ein Timeout einen Auftrag nicht ungeschehen macht
INSIGHT · 24. JANUARY 2026
API automation: Why a timeout does not undo a request
Eine Anwendung sendet einen Auftrag, wartet auf die Antwort und meldet schließlich einen Timeout. Der naheliegende nächste Schritt ist ein erneuter Versuch. Dabei kann der erste Auftrag auf dem Zielsystem längst verarbeitet worden sein.
Transportfehler und Verarbeitung unterscheiden
Ein Timeout beschreibt zunächst, dass die erwartete Antwort nicht rechtzeitig vorliegt. Daraus folgt nicht, dass die Anfrage das Ziel nie erreicht hat. Gerade bei der Anlage von Bestellungen, Tickets oder Buchungen kann eine unbedachte Wiederholung doppelte Vorgänge erzeugen.
Hier hilft das Konzept der Idempotenz: Mehrere identische Anfragen sollen hinsichtlich ihrer beabsichtigten Wirkung dasselbe Ergebnis haben wie eine einzelne Anfrage. Bei HTTP sind beispielsweise PUT und DELETE als idempotente Methoden definiert. Das bedeutet nicht, dass jede Wiederholung denselben Antwortcode liefert oder keine zusätzlichen Protokolleinträge entstehen.
Eine fachliche Vorgangskennung mitführen
Für einen neu anzulegenden Geschäftsvorgang kann eine eindeutige Kennung vereinbart werden. Erkennt das Zielsystem eine Wiederholung, verwendet es das bereits vorhandene Ergebnis. Ob und wie das unterstützt wird, gehört zum Vertrag der jeweiligen Schnittstelle; ein frei hinzugefügtes Feld allein erzeugt noch keine Duplikaterkennung.
Ein fiktives Beispiel: Ein Auftrag wird mit derselben Vorgangskennung zweimal übertragen. Das Ziel legt ihn einmal an und meldet bei der Wiederholung seinen bestehenden Status zurück. Unterschiedliche Nutzdaten unter derselben Kennung müssen als Konflikt behandelt werden.
Wiederholungen gezielt testen
Zu einem Schnittstellentest gehören deshalb verzögerte Antworten, Verbindungsabbrüche und erneute Zustellung. Außerdem ist zu klären, wie lange eine Kennung gespeichert wird und wie ein unklarer Zustand fachlich geprüft werden kann. Ein pauschales Wiederholen jeder fehlgeschlagenen Anfrage ist kein belastbares Fehlerkonzept.
An application sends a request, waits for a response and eventually reports a timeout. Retrying seems the natural next step. Yet the first request may already have been processed by the target system.
Distinguish transport failures from processing
A timeout initially means the expected response was not available in time. It does not establish that the request never reached its destination. An unconsidered retry can create duplicate transactions, particularly when creating orders, tickets or bookings.
Idempotency helps here: Repeated identical requests should have the same intended effect as a single request. In HTTP, for example, PUT and DELETE are defined as idempotent methods. This does not mean every retry returns the same status code or creates no additional log entries.
Carry a business transaction identifier
A unique identifier can be agreed for a business transaction to be created. If the target system recognises a retry, it uses the existing result. Whether and how this is supported belongs in the respective interface contract; merely adding a field does not create duplicate detection.
A fictional example: A request is transmitted twice with the same transaction identifier. The target creates it once and returns its existing status on the retry. Different payloads under the same identifier must be treated as a conflict.
Test retries deliberately
Interface testing should therefore include delayed responses, dropped connections and redelivery. The retention period for an identifier and the business-level review of an uncertain state must also be clarified. Blindly repeating every failed request is not a sound error-handling concept.