Webhook Tester

Ein Webhook-Tester ist eine temporäre öffentliche Adresse, die jede an sie gesendete HTTP-Anfrage aufzeichnet, damit Sie genau sehen, was ein Webhook-Absender tatsächlich zugestellt hat. Erstellen Sie unten einen Hook, und Sie erhalten eine eindeutige URL, die 30 Minuten lebt: Richten Sie Stripe, GitHub, einen Zahlungsanbieter, einen Monitoring-Dienst oder Ihren eigenen Code darauf, lösen Sie das Ereignis aus, und jede Zustellung landet hier — Methode, Pfad und Query, Header, Body und Quelladresse — zur Prüfung, bevor Sie den echten Handler anschließen.

Zuletzt aktualisiert:

Was dieser Dienst speichert — und was er niemals tut

Das Erstellen eines Hooks speichert auf dem SysOSX-Checker-Server nur die Hook-ID, ihre Erstellungs- und Ablaufzeit und die Adresse, die sie erstellt hat. Jede erfasste Anfrage speichert ihre Ankunftszeit, die Methode, den Pfad mit seiner Query-Zeichenkette, die Header genau wie gesendet, den Body bis zu 256 KB (alles Längere wird gekürzt und gekennzeichnet) und die Absenderadresse. Ein Hook hält höchstens 50 Anfragen; weitere Zustellungen werden abgelehnt, bis er abläuft. Alles wird 30 Minuten nach der Erstellung des Hooks gelöscht, oder sofort, wenn Sie den Lösch-Button drücken. Der Empfänger empfängt nur: Er ruft niemals etwas ab, folgt nichts und spielt nichts erneut ab — eine erfasste Anfrage löst keinerlei ausgehenden Aufruf aus. Das benachbarte Debugging-Werkzeug ist der HTTP-Statusketten-Tracer, und den vollständigen Ablauf lesen Sie in Webhooks debuggen ohne die Klempnerei.

Warum Webhook-Debugging ohne Empfänger so umständlich ist

Ein Webhook ist der Server eines anderen, der Ihren aufruft — nach dessen Zeitplan, als Reaktion auf ein Ereignis, das Sie nicht kontrollieren: eine erfolgreiche Zahlung, ein eingehender Push, ein ausgelöster Alarm. Genau diese Form macht Webhooks so mühsam zu debuggen. Der Absender erreicht Ihren Laptop nicht, also braucht die lokale Entwicklung einen Tunnel oder eine öffentliche Staging-Maschine, bevor Sie eine einzige echte Zustellung sehen; das Ereignis lässt sich womöglich kein zweites Mal auslösen, also sollte die eine Zustellung, die Sie bekommen, besser vollständig erfasst werden; und wenn etwas schiefgeht, zeigt das Dashboard des Absenders meist nur den Statuscode, den Ihr Endpunkt zurückgab — nicht das, was er tatsächlich gesendet hat. War der Signatur-Header vorhanden? War der Body die JSON-Form, die die Doku versprach, oder formkodiert? Hat der Wiederholungsversuch dieselbe Ereignis-ID gesendet? Keine dieser Fragen lässt sich allein aus den Logs Ihres Handlers beantworten, wenn Ihr Handler die Anfrage abgelehnt hat, bevor er sie protokollierte — was genau bei den Signatur- und Parsing-Fehlern geschieht, die das Webhook-Debugging dominieren.

Ein temporärer Empfänger nimmt die Klempnerei aus dieser Schleife. Statt einen halbfertigen Handler zu deployen, nur um zu sehen, was ankommt, erstellen Sie eine Adresse, die alles annimmt, es getreu aufzeichnet und Ihnen zeigt: die Header in der Reihenfolge und Schreibweise, in der sie ankamen, den rohen Body, bevor irgendein Parser ihn ablehnen konnte, die Query-Zeichenkette, in der Absender manchmal Parameter verstecken, und die genaue Methode — denn manche Anbieter stellen mit POST zu, manche mit PUT, und wenige prüfen mit GET den Zustand. Mit einer echten erfassten Zustellung auf dem Bildschirm schreiben Sie Ihren Handler gegen die Wahrheit statt gegen die Dokumentation, bauen aus der tatsächlichen Nutzlast ein Fixture für Ihre Tests und vergleichen einen fehlgeschlagenen Wiederholungsversuch Seite an Seite mit dem Original. Dann löschen Sie den Hook, richten den Anbieter auf Ihren echten Endpunkt und lösen das Ereignis noch einmal aus, um Ihrem eigenen Handler beim Antworten zuzusehen. Dreißig Minuten sind absichtlich kurz: lang genug für eine Debugging-Sitzung, kurz genug, damit eine vergessene Testadresse voller erfasster Nutzlasten nicht im Internet herumliegt.

Häufig gestellte Fragen

Wie lange lebt ein Hook, und wie viel kann er erfassen?

Ein Hook lebt ab seiner Erstellung 30 Minuten; danach werden der Hook und alles, was er erfasst hat, automatisch gelöscht. Er hält bis zu 50 Anfragen; Zustellungen darüber hinaus werden mit einer 429-Antwort abgelehnt, bis der Hook abläuft. Jeder Body wird bis zu 256 KB gespeichert — ein längerer Body wird gekürzt, und die Erfassung wird als gekürzt gekennzeichnet, damit Sie wissen, dass Sie nicht alles sehen.

Wer kann sehen, was mein Hook erfasst?

Jeder, der die Hook-URL hat. Die ID in der URL ist die einzige Berechtigung: Sie erlaubt das Senden von Anfragen und das Lesen der Erfassungen, ganz ohne Konto und Passwort darüber. Das macht das Werkzeug sofort nutzbar — und genau deshalb sollten Sie die URL wie ein Passwort behandeln: Veröffentlichen Sie sie nicht und richten Sie niemals Produktivverkehr mit Geheimnissen oder personenbezogenen Daten auf einen geteilten Viewer wie diesen.

Antwortet der Empfänger dem Absender, folgt er Links oder spielt er Anfragen erneut ab?

Nein. Der Empfänger beantwortet jede angenommene Zustellung mit einer kleinen 200-JSON-Bestätigung, dass sie angekommen ist, und tut sonst nichts damit: Er ruft niemals URLs aus einer Nutzlast ab, folgt keinen Weiterleitungen und bietet kein erneutes Abspielen und keine Weiterleitung. Empfangen und Prüfen ist der ganze Dienst, was verhindert, dass eine erfasste Nutzlast zu ausgehendem Verkehr wird.

Welche Absender kann ich damit testen?

Alles, was eine HTTP-Anfrage an eine öffentliche URL senden kann: Stripe, GitHub, Shopify, Zahlungs- und Formularanbieter, Monitoring- und CI-Dienste, ein IoT-Gerät oder Ihr eigener Code mit curl. Erstellen Sie den Hook, fügen Sie die URL in die Webhook-Einstellungen des Anbieters (oder Ihr Skript) ein, lösen Sie das Ereignis aus und sehen Sie der Zustellung zu, wie sie hier innerhalb von Sekunden ankommt. Denken Sie daran, die Test-URL danach beim Anbieter zu entfernen oder auf Ihren echten Handler zu richten.