Aus dem Englischen übersetzt. Bei Abweichungen gilt die englische Seite. Auf Englisch lesen

Webhooks testen

Teste Zustellungen von Anfang bis Ende, bevor du live gehst.

1. Ein Test-Event senden

Über das Dashboard (Einstellungen → Entwickler → Webhooks → Test-Event senden) oder über die API:

curl -X POST https://api.nembol.com/rest/v1/webhook_endpoints/{id}/test \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "type": "order.created" }'

Die Antwort sagt dir sofort, ob dein Endpoint geantwortet hat und mit welchem Status:

{ "delivered": true, "response_status": 200 }

Test-Events sind echte Zustellungen, mit demselben Format und derselben Signatur (so wird auch dein Prüfcode durchlaufen). data.object ist ein Beispiel mit der echten Struktur des angeforderten Typs (eine Bestellung, ein Angebot, ein Produkt…), aufgebaut aus erfundenen Datensätzen (TEST-SKU-1, Bestellung TEST-1001, IDs, die nirgends existieren), und data.test ist true. Dein Handler läuft von Anfang bis Ende genau wie bei einem echten Event: Prüfe data.test, bevor du etwas in dein eigenes System schreibst. Ein unbekannter type antwortet mit 422.

2. Lokale Entwicklung

Dein Entwicklungsrechner ist aus dem Internet nicht erreichbar. Möglichkeiten:

  • Richte einen Webhook-Endpoint auf einen Capture-Dienst (z. B. webhook.site), um Payloads und Header zu untersuchen. Zum Anschauen reicht das, Signaturen kann er aber nicht für dich prüfen.
  • Tunnele mit ngrok http 3000 (oder cloudflared) zu localhost und registriere die Tunnel-URL als Endpoint im Testmodus. Das ist der vollständige End-to-End-Kreislauf: Signaturprüfung, dein Handler, dein 2xx.

3. Schlüssel und Webhooks im Testmodus

Webhook-Endpoints, die mit einem nbl_test_-Schlüssel erstellt wurden, erhalten nur synthetische Events (Testsendungen und simulierte Operations), nie Produktions-Traffic. Live-Endpoints erhalten nur echte Events. Halte beide in deiner Konfiguration getrennt.

4. Checkliste vor dem Livegang

  • Signaturprüfung aktiv (und sie schlägt fehl, wenn du ein Byte veränderst).
  • Der Handler antwortet in < 10 s mit 2xx; aufwendige Arbeit läuft asynchron.
  • Eine doppelte event.id bewirkt nichts (Zustellungen sind at-least-once).
  • Unbekannte type-Werte werden bestätigt, nicht als Fehler behandelt.
  • Ein Abgleich-Job durchläuft GET /events nach allem, was verpasst wurde.

Zuletzt aktualisiert am 20. Oktober 2026

Brauchst du Hilfe?

Schreib uns, und ein Mensch antwortet, meist innerhalb eines Werktags.

Auf dieser Seite