Testen
Sende zuerst einen Test aus den Webhook-Einstellungen. Damit prüfst du Ziel-Adresse, Header, Signatur und Antwort des Empfängers, ohne einen echten CRM-Datensatz anzulegen oder zu ändern.
Zuletzt geprüft: 15. September 2026
Test aus i-Planner senden
Unten auf der Webhook-Detail-Seite gibt es den Abschnitt Webhook testen. Dort wählst du:
Event- Wähle eines der im Webhook aktivierten Events oder den Verbindungstest. Der Verbindungstest ist immer verfügbar — auch wenn noch kein Event aktiviert ist.
Ein Klick auf Test senden schickt sofort einen Aufruf an die konfigurierte URL. Der Test verwendet denselben äußeren Aufbau und dieselben Signatur-Header wie eine produktive Zustellung. Unter payload steht jedoch bewusst ein Testhinweis statt eines echten CRM-Datensatzes:
{
"request_id": "9a8b7c…",
"event_name": "customers.insert",
"timestamp": "2026-09-10T08:00:00.000Z",
"payload": {
"test": true,
"message": "Webhook-Test aus den Settings",
"triggered_at": "2026-09-10T08:00:00.000Z"
}
}
Der Test beantwortet die Frage: „Kann i-Planner meinen Empfänger sicher erreichen und antwortet er korrekt?“ Ein erfolgreicher Test gibt bei einem inaktiven Webhook den Aktiv-Schalter frei, schaltet ihn aber nicht selbst ein. Er beweist nicht, dass die fachlichen Daten eines bestimmten Events verarbeitet werden. Dafür muss das gewählte Event tatsächlich in i-Planner oder über die REST-API ausgelöst werden. Ändern sich später Ziel-URL, HTTP-Methode, Content-Type oder Header, ist ein neuer erfolgreicher Test vor der nächsten Aktivierung erforderlich.
Im Abschnitt Request / Response siehst du nach dem Test:
Request- Methode, Ziel-URL, maskierte Header und den logischen Test-Inhalt. Bei
application/x-www-form-urlencodedwird dieser Inhalt für den tatsächlichen Versand form-codiert; die Anzeige ist nicht der exakte HTTP-Body. Response- Status-Code, Antwortzeit (ms), ausgewählte sichere Antwort-Header und bis zu 64 KiB des Antwort-Bodys. Weitere Header und längere Bodies werden nicht angezeigt. Bei Netzwerk- oder TLS-Fehlern steht hier der entsprechende Fehlertyp.
Badge in der Übersicht- Die Webhook-Übersicht und der Kopf der Detail-Seite zeigen das letzte Test-Ergebnis als Badge „Letzter Test erfolgreich“ oder „Letzter Test Fehler“. Der farbige Punkt vor dem Namen ist davon unabhängig und zeigt den Zustand des Webhooks — rot = inaktiv, gelb = aktiv ohne Events, grün = aktiv mit Events.
Der Test umgeht Warteschlange, Wiederholungen und Auto-Deaktivierung — er ist ein einmaliger Aufruf, kein echtes Event. Der request_id-Wert ist eine echte UUID, damit du ihn beim Empfänger sauber zuordnen kannst. Test-Aufrufe werden nicht als produktive Zustellungen im Audit-Log gespeichert.
Häufige Fehler verstehen
Schlägt der Test fehl, steht im Abschnitt Response ein Fehlercode wie TIMEOUT, HTTP_404 oder FETCH_ERROR. Was er bedeutet und was du tun kannst, steht unter Fehlerbehebung → Fehlercodes.
Lokal testen – für Entwickler
i-Planner kann nur öffentlich erreichbare URLs aufrufen — localhost ist tabu (siehe URL-Validierung). Für lokale Entwicklung gibt es zwei pragmatische Wege:
ngrokngrok http 3000öffnet einen öffentlichen HTTPS-Tunnel auf deinen lokalen Port. Die ausgegebene URL (https://xxxx.ngrok-free.app) trägst du in die Webhook-Konfiguration ein — i-Planner sieht eine ganz normale öffentliche Adresse.Cloudflare Tunnelcloudflared tunnel --url http://localhost:3000macht dasselbe ohne Account, mit einer wegwerfbaren*.trycloudflare.com-URL. Praktisch für schnelle Tests.
Ein minimaler Empfänger zum Mitschreiben:
# Simuliert den i-Planner-Webhook lokal — feuere damit an den Tunnel
# (ngrok / cloudflared) oder direkt auf 127.0.0.1, um zu sehen, was
# dein Empfänger empfängt und antwortet.
curl -v -X POST http://localhost:3000/webhooks/iplanner \
-H "Content-Type: application/json" \
-H "Authorization: Bearer test-token" \
-d '{
"request_id": "9a8b7c-test",
"event_name": "customers.insert",
"timestamp": "2026-09-10T08:00:00.000Z",
"payload": {
"test": true,
"message": "Lokaler Webhook-Test",
"triggered_at": "2026-09-10T08:00:00.000Z"
}
}'
Sobald der Tunnel steht, wählst du im Bereich Webhook testen ein Event aus und sendest den Test. Du siehst den Aufruf anschließend im lokalen Terminal und in den Einstellungen unter Request / Response.