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.idbewirkt nichts (Zustellungen sind at-least-once). - Unbekannte
type-Werte werden bestätigt, nicht als Fehler behandelt. - Ein Abgleich-Job durchläuft
GET /eventsnach allem, was verpasst wurde.
Zuletzt aktualisiert am 20. Oktober 2026
Brauchst du Hilfe?
Schreib uns, und ein Mensch antwortet, meist innerhalb eines Werktags.