Ein erneuter Sendeversuch (Retry) darf nicht unbemerkt zu einem veränderten Kaufbeleg führen. Läuft ein Node-Job in ein Timeout und greift der nächste Versuch auf ein inzwischen bearbeitetes Template oder veränderte Bestelldaten zu, lässt sich im Team oft nicht mehr nachvollziehen, welche Nachricht Kund:innen tatsächlich erhalten haben.
Erstellen Sie das freigegebene Belegdesign in Migma und stellen Sie sicher, dass die Verantwortlichen für Node und Loops die verbindlichen Transaktionsdaten sichern und unklare Sendeergebnisse vor einem weiteren Versuch abgleichen. Dieser Leitfaden von Migma konzentriert sich auf die inhaltliche und gestalterische Abstimmung bei Retries – nicht auf die Einrichtung einer Versandintegration oder die automatische Steuerung von Loops durch Migma.
Festlegen, was als dieselbe Nachricht gilt
Nehmen wir als Beispiel eine fiktive Bestellung über zwei Notizbücher. Der vorgesehene Beleg nennt die Artikel, die freigegebenen Beträge und die Bestellnummer. Diese Angaben definieren ein konkretes geschäftliches Ereignis. Eine spätere Rückerstattung oder Adresskorrektur ist eine separate Änderung, die ausdrücklich geprüft werden muss – und nicht beiläufig in einem Retry untergehen darf.
Halten Sie kurz fest, was mit dem ersten Versand übermittelt werden sollte: Ereignisreferenz, vorgesehene Empfänger:innen, geprüfte Template-Version, erforderliche Variablen und die Zuständigkeiten für die einzelnen Datenpunkte. Unnötige Zahlungs- oder Personendaten gehören nicht in die Review-Notizen des Design-Workflows.
Die entscheidende Frage lautet nicht einfach: „Wurde der Code erneut ausgeführt?“ Sie lautet: „Sollte der nächste Versuch dasselbe freigegebene Ereignis an dieselbe Person übermitteln?“ Ändert sich die Antwort, handelt es sich nicht mehr um einen gewöhnlichen Retry – klären Sie mit dem verantwortlichen Team, wie eine Korrektur ablaufen soll.
Designfreigabe und Sendeidentität trennen
Der dokumentierte Workflow von Migma bereitet Text, Design, Bilder und ein E-Mail-kompatibles Markup für das Review vor. Damit eignet er sich ideal, um Layout und Wording eines Belegs verbindlich abzustimmen. Er erfasst jedoch nicht, welche API-Anfrage vom Provider akzeptiert wurde oder ob Kund:innen die Nachricht bereits erhalten haben.
Halten Sie das freigegebene Design gemeinsam mit der Zuordnung von Ereignis zu Template fest. Nutzt das Zielsystem ein geteiltes Loops-Template, muss geklärt sein, wie Änderungen kontrolliert werden, solange ein Sendeauftrag noch aussteht. Ein lokal gespeicherter Screenshot friert das im Produktivsystem genutzte Template nicht ein.
Prüfen Sie neben den Fakten auch die verknüpften Aktionen: Ein Link zum Bestellstatus muss genau auf den referenzierten Auftrag verweisen. Ein generischer Button wie „Bestellung ansehen“ schützt nicht vor einem falschen Ziel. Bitten Sie die technische Zuständigkeit, befüllte Beispiele zu prüfen – nicht nur leere Variablennamen.
Den aktuellen Retry-Vertrag des Providers nutzen
Die Node-Ressource von Loops beschreibt den Transaktionsversand und den Umgang mit Retries. Das exakte Verhalten entnehmen Sie der Dokumentation des Transactional-Endpoints (geprüft für diesen Leitfaden am 17. Oktober 2026).
Der Endpoint unterstützt einen optionalen Idempotency-Key zur Vermeidung doppelter Anfragen und liefert einen 409-Status zurück, wenn ein Key innerhalb des definierten Zeitfensters bereits verwendet wurde. Das zuständige Entwicklerteam muss diesen Vertrag korrekt anwenden: Ein neuer Key, der lediglich gewählt wird, um einen Konflikt zu umgehen, hebelt den Schutz vor Doppelversand aus.
Dieser Artikel enthält keinen Retry-Code und kein universelles Rezept zur Fehlerbehandlung. Das zuständige Engineering-Team muss festlegen, wie temporäre Fehler, permanente Fehlschläge und unklare Antworten protokolliert und abgeglichen werden. Die kreative Freigabe liefert dafür die stabilen Nachrichteninhalte, statt eigene Zustellungsstatus zu erfinden.
Drei Szenarien vor dem Release prüfen
Bestätigen Sie bei einem unveränderten Retry, dass Ereignis, Empfängeradresse, Datenwerte und freigegebener Inhalt identisch geblieben sind. Klären Sie, wie der Job diese freigegebene Version referenziert und wie die Zuständigen das Provider-Ergebnis später einsehen können.
Identifizieren Sie bei einem geänderten Beleg, was sich geändert hat und warum. Eine korrigierte Menge, eine Rückerstattung oder geänderte Empfängerdaten erfordern häufig eine separat freigegebene Kommunikation. Überschreiben Sie nicht die Aussage der ursprünglichen Nachricht, nur damit der jüngste Screenshot optisch passt.
Halten Sie bei einer unklaren Antwort die Unsicherheit fest, bis das sendende System das tatsächliche Ergebnis ermittelt hat. Ein Timeout belegt nicht, dass der Provider nichts verarbeitet hat. Der Wunsch, „zur Sicherheit noch einmal zu senden“, darf nicht dazu führen, dass unkontrolliert ein zweiter Beleg über alternative Pfade verschickt wird.
Das final gerenderte Template verifizieren
Nutzen Sie den HTML-Export von Migma als freigegebene Design-Referenz. Das Loops-Team muss die unterstützte Implementierung des Designs und die Befüllung der Variablen bestätigen. Dieser Leitfaden setzt keine native Verbindung zwischen Migma und Loops voraus.
Testen Sie reale Grenzfälle: Belege mit mehreren Artikeln, langen Produktnamen, fehlenden optionalen Werten und korrigierten Aufträgen. Erforderliche Transaktionsdaten dürfen nicht durch plausible Schätzwerte ersetzt werden. Fehlt ein geschäftskritischer Wert, muss fachlich entschieden werden, ob die Nachricht dennoch präzise versendet werden kann.
Führen Sie Email Preflight für Texte, Links, Layout und Posteingangsvorschauen durch. Nutzen Sie anschließend den kontrollierten Testablauf des Versand-Setups für das finale Ziel-Template und alle Retry-Fälle. Eine Designprüfung kann weder die Bestätigung durch den Provider ersetzen noch die Posteingangszustellung garantieren.
Korrekturen für das gesamte Team transparent halten
Sichern Sie freigegebene Inhalte, Ereignis-Mappings, Testfälle und die Zuständigkeiten für den Datenabgleich an einem gemeinsamen Ort. Wird ein geteiltes Template geändert, sprechen Sie die Auswirkungen auf ausstehende Jobs mit dem Engineering-Team ab, bevor Sie annehmen, dass nur künftige Nachrichten betroffen sind.
So entsteht ein verlässlicher Beleg, den das Team jederzeit nachvollziehen kann: welcher Inhalt formuliert wurde, welches geschäftliche Ereignis zugrunde liegt und welche Versanddaten den Status belegen. Starten Sie das Creative in Migma und verknüpfen Sie Retry-Entscheidungen direkt mit den realen Provider- und Anwendungsdaten.
Frequently Asked Questions
Bedeutet ein Timeout, dass der Beleg nicht versendet wurde?
Nein. Auch bei einem Timeout kann der Provider die Anfrage bereits verarbeitet haben. Das sendende Team sollte das tatsächliche Ergebnis abgleichen, bevor ein weiterer Versuch unternommen wird.
Sollte nach einer 409-Antwort von Loops ein neuer Key generiert werden?
Ein neuer Key sollte nicht verwendet werden, nur um einen Konflikt zu umgehen. Prüfen Sie die aktuelle Endpoint-Spezifikation und gleichen Sie das ursprüngliche Ereignis, die Anfrage und das Provider-Ergebnis mit den Zuständigen ab.
Friert die Freigabe eines Migma-Screenshots das Loops-Template ein?
Nein. Dokumentieren Sie, wie das Ziel-Template und ausstehende Jobs auf den freigegebenen Stand verweisen. Ein Screenshot dient als Abstimmungsreferenz, steuert jedoch kein externes Versandsystem.
Gilt ein geänderter Beleg weiterhin als regulärer Retry?
Änderungen an Empfängern, Transaktionsdaten oder dem Kommunikationszweck erfordern eine erneute Freigabe. Die zuständige Person muss entscheiden, ob es sich um eine Korrektur oder eine separate Nachricht handelt, statt die ursprüngliche Aussage stillschweigend zu ersetzen.