Webhooks per KI verwalten

Der KI-Agent kann ausgehende Webhooks registrieren, die bei bestimmten Shop-Ereignissen (Bestellstatus-Änderung, Lageränderung usw.) eine HTTP-Anfrage an eine externe URL senden. Fehlgeschlagene Zustellungen können erneut ausgelöst werden.

Der entsprechende Admin-Bereich ist Einstellungen → Webhooks (oder Entwickler → Webhooks).

Webhooks auflisten

„Liste alle aktiven Webhooks auf."

Für eine gefilterte Ansicht:

„Zeige mir alle fehlgeschlagenen Webhooks der letzten 7 Tage."

„Welche Webhooks sind für das Ereignis ‚order.status.updated' konfiguriert?"

Filtermöglichkeiten: Status (pending, sent, failed) und Ereignistyp.

Webhook erstellen

„Erstelle einen Webhook für das Ereignis ‚order.status.updated', der an ‚https://mein-system.de/webhooks/bestellungen' sendet."

Pflichtfelder beim Anlegen:

Feld	Beschreibung
URL	Ziel-Endpunkt (muss SSRF-Validierung bestehen, siehe unten)
Ereignistyp	Eines der 8 erlaubten Ereignisse (siehe Liste unten)
Payload-Template	JSON-Template mit Platzhaltern für Ereignisdaten (optional, Standard-Template wird verwendet)

Erlaubte Ereignistypen

Ereignis	Wird ausgelöst bei
`order.status.updated`	Bestellstatus wird geändert
`order.tracking.updated`	Trackingnummer wird hinzugefügt oder geändert
`order.shipping.updated`	Versandinformationen werden aktualisiert
`stock.changed`	Lagerbestand eines Produkts ändert sich
`stock.low`	Lagerbestand fällt unter den Meldebestand
`inventory.production_order_created`	Produktionsauftrag wird angelegt
`inventory.production_order_completed`	Produktionsauftrag wird abgeschlossen
`inventory.production_order_status_changed`	Status eines Produktionsauftrags ändert sich

URL-Validierung (SSRF-Schutz)

Der Agent prüft jede Webhook-URL vor dem Speichern auf Sicherheitsrisiken. Folgende URLs werden abgewiesen:

Private IP-Bereiche: 10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x
Localhost und Loopback: 127.x.x.x, localhost, ::1
Nicht-HTTP-Schemata: ftp://, file://, javascript: usw.

Erlaubt sind nur https:// und http://-URLs mit öffentlich erreichbaren Adressen. Für lokale Tests empfiehlt sich ein Tool wie ngrok oder ein dedizierten Testendpunkt.

Webhook aktualisieren

URL, Ereignistyp oder Payload-Template lassen sich nachträglich ändern:

„Ändere die URL des Webhooks mit der ID 7 auf ‚https://neues-system.de/hooks/orders'."

Fehlgeschlagene Zustellung erneut auslösen

Wenn ein Webhook nicht zugestellt werden konnte (Status failed) oder erneut getestet werden soll (Status sent):

„Löse den Webhook mit der ID 23 erneut aus."

Der Agent setzt den Zustellstatus zurück, sodass der Hintergrundprozess den Webhook erneut verarbeitet. Die tatsächliche Zustellung erfolgt nicht sofort — sie wird beim nächsten Durchlauf des Retry-Prozessors ausgeführt.

Wichtig: Ein Webhook mit Status pending (Zustellung steht aus) kann nicht erneut ausgelöst werden — er wartet bereits auf Zustellung.

Webhook löschen

„Lösche den Webhook mit der ID 7 — er wird nicht mehr benötigt."

Das Löschen entfernt den Webhook und alle zugehörigen Zustellungsprotokolle.

Häufige Anwendungsfälle

ERP-System bei Bestelleingang benachrichtigen:

„Erstelle einen Webhook für ‚order.status.updated', der an ‚https://erp.mein-unternehmen.de/api/orders' sendet."

Lagerwarnung an Slack senden:

„Erstelle einen Webhook für ‚stock.low', der an ‚https://hooks.slack.com/services/...' sendet."

Fehlgeschlagene Webhooks nach Serverausfall neu starten:

„Zeige mir alle fehlgeschlagenen Webhooks und löse sie erneut aus."

Hinweise

Webhooks werden vom Hintergrundprozessor zugestellt, nicht sofort beim Ereignis. Bei hoher Last kann eine kurze Verzögerung entstehen.
Das Payload-Template bestimmt die JSON-Struktur der gesendeten Anfrage. Ohne eigenes Template wird ein Standard-Payload mit den wichtigsten Ereignisdaten verwendet.
Es sind genau 8 Ereignistypen erlaubt — andere Typen werden vom Agenten mit einem Fehler abgewiesen.