Webhook-Zustellungen verfolgen und erneut senden

Rückblick - März 2026
Dieser Artikel wurde nachträglich verfasst und beschreibt das während dieses Zeitraums eingeführte öffentliche Zustellungsprotokoll.

Wenn ein Webhook-Empfänger nicht wie erwartet antwortet, können Sie die Zustellung untersuchen, ohne manuell ein neues Geschäftsereignis anzulegen. Öffnen Sie das Zustellungsprotokoll in Alunta oder rufen Sie die Liste über die API ab, um Status, Versuche und öffentliche Zustellungsdetails einzusehen.

Der Status failed bedeutet normalerweise, dass Sie den Empfänger oder dessen Validierung korrigieren müssen. dispatching bedeutet, dass die Zustellung noch gesendet wird. Für eine abgeschlossene Zustellung verwendet die API außerdem succeeded. In Filtern schließt failed Zustellungen mit dem Status dispatching aus; verwenden Sie den separaten Wert dispatching, wenn Sie diese anzeigen möchten. Die genauen Feldnamen und Status finden Sie in der aktuellen API-Referenz.

Zustellung erneut senden

Wählen Sie eine fehlgeschlagene Zustellung aus und verwenden Sie die Aktion zum erneuten Senden. Dabei wird dieselbe externe Nachricht erneut gesendet; es entsteht kein neues Abonnement- oder Rechnungsereignis. Der Empfänger muss daher data.event_id deduplizieren, wenn der Ereignistyp einen stabilen Schlüssel dokumentiert, webhook_uuid nach Möglichkeit als Zustellungskennung verwenden und mehrfach zugestellte Ereignisse tolerieren. Separate Versuche von subscription.payment_failed müssen als eigenständige Zustellungen erhalten bleiben.

Das erneute Senden behebt einen Fehler in Ihrem System nicht automatisch. Prüfen Sie zuerst Endpunkt, Signaturprüfung und Ereignisverarbeitung und bestätigen Sie anschließend das Ergebnis im Zustellungsprotokoll.

Die Anleitung zu öffentlicher API und Webhooks (Markdown-fil, AI-agentvenlig) beschreibt das aktuelle Protokoll und den erneuten Versand.

Sicherer Ablauf zum erneuten Senden

Verwenden Sie in Ihrem Testempfänger ein fiktives, nicht vorhandenes Ereignis mit der UUID 00000000-0000-4000-8000-000000000004. Prüfen Sie vor dem erneuten Senden, dass der Empfänger den relevanten stabilen Ereignisschlüssel speichert und schnell antwortet. Bei einem Ereignistyp mit data.event_id wird derselbe Schlüssel erneut zugestellt und der Empfänger führt die Geschäftsaktion nicht doppelt aus; wenn webhook_uuid vorhanden ist, kennzeichnet er die Zustellung. Prüfen Sie anschließend den Zustellungsstatus. Erhalten Sie separate Versuche von subscription.payment_failed. Schlägt die Zustellung weiterhin fehl, korrigieren Sie den Empfänger erneut, statt manuell ein Abonnementereignis anzulegen.

Beim erneuten Senden wird eine Nachricht wiederholt, keine Zahlung. Löst das externe System aufgrund des Ereignisses eine Aktion aus, muss auch diese idempotent sein.

Wenn sich der Status nicht ändert

Ein erfolgreicher erneuter Versand bedeutet, dass der Empfänger die Zustellung angenommen hat, nicht, dass die interne Verarbeitung korrekt ist. Berücksichtigen Sie sowohl Aluntas Zustellungsstatus als auch Ihr eigenes Eingangsprotokoll. dispatching ist nicht gleichbedeutend mit failed oder succeeded, und keiner dieser Werte ist selbst ein Abonnement- oder Zahlungsstatus.

Sendet ein erneuter Versuch einen Ereignistyp, den Sie nicht mehr verwenden, sollte der Empfänger ihn weiterhin sicher verarbeiten und gemäß seiner Richtlinie als ignoriert kennzeichnen. Löschen Sie den Verlauf nicht, um einen Fehler zu „beheben“; korrigieren Sie den Empfänger und verwenden Sie die dokumentierte Aktion zum erneuten Senden.