Debuggen Sie Webhooks ohne Bereitstellung: ein temporärer Posteingang, den Sie in 10 Sekunden einrichten können

Sie möchten sehen, was Stripe sendet, wenn eine Zahlung erfolgreich ist. Oder was GitHub sendet, wenn jemand eine Pull-Anfrage öffnet. Der Standardansatz: Einen lokalen Server starten, ngrok installieren, einen Tunnel konfigurieren, ein Terminalfenster geöffnet lassen, die Sitzung hoffen läuft während des Tests nicht ab. Oder noch schlimmer: Stellen Sie einen halbfertigen Handler für Staging- und Tail-Logs bereit, während Sie warten.

Beide Arbeitsabläufe verschwenden Zeit für die Infrastruktur, wenn die eigentliche Frage einfach ist: *Wie sieht die Nutzlast aus?*

Botois Webhook-Posteingang bietet Ihnen eine verfügbare URL, die eingehende Nutzlasten erfasst und 24 Stunden lang speichert. Drei API-Aufrufe. Keine Konten, keine Tunnel, keine Server.

Der 3-Schritte-Workflow

1. Erstellen Sie einen Posteingang um eine eindeutige Empfangs-URL zu erhalten
2. Zeigen Sie auf Ihre Webhook-Quelle unter dieser URL
3. Listen Sie die Nutzlasten auf um zu prüfen, was angekommen ist

Jeder Schritt ist ein einzelner curl Befehl.

Schritt 1: Erstellen Sie einen Posteingang

curl -X POST https://api.botoi.com/v1/webhook/inbox/create

Antwort:

{
  "success": true,
  "data": {
    "inbox_id": "a1b2c3d4",
    "url": "https://api.botoi.com/v1/webhook/inbox/a1b2c3d4/receive",
    "expires_in": 86400
  }
}

Speichern Sie die inbox_id Und url Werte. Der Posteingang bleibt dann 24 Stunden (86.400 Sekunden) bestehen Die URL und alle gespeicherten Payloads werden gelöscht.

Schritt 2: Senden Sie einen Webhook an den Posteingang

Zeigen Sie Ihren Webhook-Anbieter auf url ab Schritt 1. Der Posteingang akzeptiert jeden JSON-Text:

curl -X POST https://api.botoi.com/v1/webhook/inbox/a1b2c3d4/receive \\
  -H "Content-Type: application/json" \\
  -d '{
    "event": "payment_intent.succeeded",
    "amount": 4999,
    "currency": "usd",
    "customer_email": "buyer@example.com"
  }'

Antwort:

{
  "success": true,
  "data": {
    "received": true,
    "payload_id": "e5f6g7h8"
  }
}

Schritt 3: Überprüfen Sie die Nutzlasten

curl -X POST https://api.botoi.com/v1/webhook/inbox/a1b2c3d4/list

Antwort:

{
  "success": true,
  "data": {
    "inbox_id": "a1b2c3d4",
    "payloads": [
      {
        "id": "e5f6g7h8",
        "received_at": "2026-03-26T10:00:00Z",
        "body": {
          "event": "payment_intent.succeeded",
          "amount": 4999,
          "currency": "usd",
          "customer_email": "buyer@example.com"
        }
      }
    ],
    "count": 1
  }
}

Jede Nutzlast wird mit einem Zeitstempel und einer eindeutigen ID gespeichert. Sie können den Listenendpunkt beliebig oft aufrufen innerhalb des 24-Stunden-Fensters.

Beispiel aus der Praxis: Debuggen eines Stripe-Webhooks

Mit dem Testmodus von Stripe können Sie Ereignisse über das Dashboard auslösen. Anstatt einen Server aufzustellen, um sie zu empfangen, Zeigen Sie Stripe auf die URL Ihres Posteingangs.

1. Erstellen Sie den Posteingang

INBOX=\$(curl -s -X POST https://api.botoi.com/v1/webhook/inbox/create)
INBOX_ID=\$(echo \$INBOX | jq -r '.data.inbox_id')
INBOX_URL=\$(echo \$INBOX | jq -r '.data.url')
echo "Inbox URL: \$INBOX_URL"

2. Fügen Sie die URL zu Stripe hinzu

Gehe zu Stripe-Dashboard > Entwickler > Webhooks. Klicken Sie auf „Endpunkt hinzufügen“ und fügen Sie den ein INBOX_URL. Wählen Sie die Ereignisse aus, die Ihnen am Herzen liegen. wie payment_intent.succeeded Und invoice.payment_failed.

3. Lösen Sie ein Testereignis aus

Klicken Sie im Stripe-Dashboard auf „Test-Webhook senden“. Dann überprüfen Sie, was angekommen ist:

curl -s -X POST "https://api.botoi.com/v1/webhook/inbox/\$INBOX_ID/list" | jq '.data.payloads'

Sie verfügen nun über die genaue Nutzlast, die Stripe sendet, mit allen verschachtelten Objekten, Feldnamen und Typen. Verwenden Sie dies, um Ihren Handler sicher zu schreiben, anstatt über das Schema zu raten.

Beispiel aus der Praxis: Testen einer GitHub-Webhook-Integration

GitHub-Repository-Webhooks werden bei Ereignissen wie ausgelöst push, pull_request, Und issues. Hier erfahren Sie, wie Sie einen erfassen, ohne lokal Code auszuführen.

1. Erstellen Sie einen Posteingang und konfigurieren Sie GitHub

# Create the inbox
INBOX=\$(curl -s -X POST https://api.botoi.com/v1/webhook/inbox/create)
INBOX_URL=\$(echo \$INBOX | jq -r '.data.url')
INBOX_ID=\$(echo \$INBOX | jq -r '.data.inbox_id')

# Add webhook to your repo via GitHub API
curl -X POST \\
  -H "Authorization: token \$GITHUB_TOKEN" \\
  -H "Content-Type: application/json" \\
  "https://api.github.com/repos/your-org/your-repo/hooks" \\
  -d "{
    \\"config\\": {
      \\"url\\": \\"\$INBOX_URL\\",
      \\"content_type\\": \\"json\\"
    },
    \\"events\\": [\\"pull_request\\"]
  }"

2. Öffnen Sie eine Pull-Anfrage und überprüfen Sie dann den Posteingang

curl -s -X POST "https://api.botoi.com/v1/webhook/inbox/\$INBOX_ID/list" \\
  | jq '.data.payloads[0].body | {action, number: .pull_request.number, title: .pull_request.title}'

Ausgabe (Beispiel):

{
  "action": "opened",
  "number": 42,
  "title": "Add rate limiting to /api/orders"
}

Sie können die genaue Struktur sehen, die GitHub sendet, einschließlich Feldern wie action, sender, repository, und das volle pull_request Objekt. Dies ist schneller als das Lesen der GitHub-Dokumente und das Erraten, welche Felder für jeden Ereignistyp ausgefüllt sind.

Automatisieren: ein Testskript

Dieses Bash-Skript erstellt einen Posteingang, sendet eine Testnutzlast, ruft sie ab und überprüft den Roundtrip. Speichern Sie es unter test-webhook.sh und führen Sie es aus, um zu bestätigen, dass Ihre Integration durchgängig funktioniert.

#!/bin/bash
set -euo pipefail

API="https://api.botoi.com/v1/webhook/inbox"

echo "Creating inbox..."
INBOX=\$(curl -s -X POST "\$API/create")
INBOX_ID=\$(echo "\$INBOX" | jq -r '.data.inbox_id')
INBOX_URL=\$(echo "\$INBOX" | jq -r '.data.url')
echo "Inbox ID: \$INBOX_ID"
echo "Receive URL: \$INBOX_URL"

echo ""
echo "Sending test payload..."
SEND=\$(curl -s -X POST "\$INBOX_URL" \\
  -H "Content-Type: application/json" \\
  -d '{
    "event": "order.created",
    "order_id": "ord_98765",
    "total": 129.99,
    "items": [
      {"sku": "WIDGET-A", "qty": 2},
      {"sku": "GADGET-B", "qty": 1}
    ]
  }')

PAYLOAD_ID=\$(echo "\$SEND" | jq -r '.data.payload_id')
echo "Payload ID: \$PAYLOAD_ID"

echo ""
echo "Retrieving payloads..."
LIST=\$(curl -s -X POST "\$API/\$INBOX_ID/list")
COUNT=\$(echo "\$LIST" | jq -r '.data.count')

if [ "\$COUNT" -ge 1 ]; then
  echo "Success: \$COUNT payload(s) received"
  echo "\$LIST" | jq '.data.payloads[0].body'
else
  echo "Error: no payloads found"
  exit 1
fi

Erwartete Ausgabe:

Creating inbox...
Inbox ID: a1b2c3d4
Receive URL: https://api.botoi.com/v1/webhook/inbox/a1b2c3d4/receive

Sending test payload...
Payload ID: e5f6g7h8

Retrieving payloads...
Success: 1 payload(s) received
{
  "event": "order.created",
  "order_id": "ord_98765",
  "total": 129.99,
  "items": [
    {"sku": "WIDGET-A", "qty": 2},
    {"sku": "GADGET-B", "qty": 1}
  ]
}

Vergleich: Botoi-Posteingang vs. die Alternativen

Besonderheit	Botoi-Posteingang	ngrok	webhook.site	RequestBin
Rüstzeit	Ein Curl-Befehl	Installieren Sie CLI + Authentifizierung	Browser öffnen	Browser öffnen
Lokaler Server erforderlich	NEIN	Ja	NEIN	NEIN
Konto erforderlich	NEIN	Ja (kostenloses Kontingent)	Nein (begrenzt)	Ja
Programmgesteuerter Zugriff	Vollständige API	API (kostenpflichtig)	API (kostenpflichtig)	API (kostenpflichtig)
CI/CD-freundlich	Ja; Curl + jq	Möglich; Komplex	NEIN	NEIN
TTL	24 Stunden	Sitzungsbasiert	Variiert	48 Stunden
Der Prozess läuft weiter	NEIN	Ja	NEIN	NEIN
Frei	Ja	Beschränkt	Beschränkt	NEIN

Der Hauptvorteil des Botoi-Posteingangs besteht darin, dass alles über die API geschieht. Sie können Posteingänge erstellen und Tests senden Nutzlasten und rufen Sie Ergebnisse in Shell-Skripten, CI-Pipelines und Integrationstests ab, ohne einen Browser zu öffnen oder einen Hintergrundprozess am Leben zu erhalten.

Wann ist dies zu verwenden?

• Erkundung eines neuen Webhook-Anbieters. Erfassen Sie vor dem Schreiben von Handlercode echte Nutzlasten, um sie zu verstehen die Datenform, Feldnamen und Randfälle.
• Integrationstests in CI. Richten Sie in Ihrer Testsuite einen Posteingang ein, lösen Sie den Webhook aus und fragen Sie die Liste ab Endpunkt und bestätigen Sie den Inhalt der Nutzlast.
• Debuggen eines defekten Handlers. Tauschen Sie Ihre Produktions-Webhook-URL vorübergehend gegen eine Posteingangs-URL aus Erfassen Sie die genaue Nutzlast, die Fehler verursacht.
• Paarprogrammierung oder Demos. Teilen Sie die Posteingangs-ID mit einem Teamkollegen. Sie beide können Nutzlasten senden und Überprüfen Sie die Ergebnisse verschiedener Maschinen.

Der Posteingang ist von Natur aus wegwerfbar. Erstellen Sie bei Bedarf eines, verwenden Sie es für die Sitzung und lassen Sie es ablaufen. Keine Bereinigung, keine verbleibenden Endpunkte, keine Überraschungen bei der Abrechnung.