Webhooks
Verwaltungsseite für Webhook-Registrierungen im Shopware 6-Shop. Webhooks ermöglichen Echtzeit-Benachrichtigungen bei Ereignissen im Shop (z. B. neue Bestellung, Statusänderung), ohne dass Business Central aktiv den Shop abfragen muss.
Seite öffnen
- Über die Suche: Shopware 6-Webhooks
- Über das Shopware 6-Dashboard → Erweitert → Webhooks
Felder
| Feld | Beschreibung |
|---|---|
| Shop-Code | Shop, für den der Webhook registriert ist. |
| Ereignisname | Shopware-Event-Name (z. B. order.placed, order.state_machine.order.delivery.state_changed). |
| Webhook-URL | Endpunkt-URL, an die Shopware die Events sendet (typischerweise eine Azure Function). |
| Aktiv | Bestimmt, ob der Webhook aktiv ist und Events empfängt. |
| Shopware-Webhook-ID | UUID der Registrierung im Shopware-Shop (standardmäßig ausgeblendet). Wird beim Registrieren gesetzt und beim Abmelden geleert. |
Aktionen
| Aktion | Beschreibung |
|---|---|
| Registrieren | Registriert den markierten Webhook im Shop. Ist er schon registriert, wird die Registrierung aktualisiert – eine geänderte URL kommt so im Shop an. |
| Abmelden | Entfernt den markierten Webhook aus dem Shop – alle seine Registrierungen, auch Kopien mit gleichem Namen, Ereignis und URL. |
| Alle ausstehenden registrieren | Registriert alle aktiven Webhooks, die noch keine Shopware-Webhook-ID haben – jeden in seinem Shop. Fragt vorher nach. |
| Standard-Webhooks einrichten | Legt für jeden aktivierten Shop die Zeilen der unterstützten Ereignisse an (Bestellung, Status, Artikel, Kunde). Registriert wird danach mit Alle ausstehenden registrieren. |
Keine doppelten Registrierungen
Vor dem Registrieren sucht Business Central im Shop nach einem Webhook mit gleichem Namen, Ereignis und gleicher URL. Ein Treffer wird übernommen, weitere exakte Kopien werden gelöscht – jede Kopie würde jedes Ereignis erneut ausliefern.
Webhook-Ereignisse
Die Seite Webhook-Ereignisse (Dashboard → Erweitert → Webhook-Ereignisse) zeigt alle empfangenen Events:
| Feld | Beschreibung |
|---|---|
| Lfd. Nr. | Laufende Nummer des Ereignisses. |
| Ereignisname / Ereignis-Aktion | Typ des empfangenen Events. |
| Entitäts-ID | UUID des betroffenen Datensatzes im Shop. |
| Status | Ausstehend, In Bearbeitung, Abgeschlossen oder Fehlgeschlagen. |
| Fehlermeldung / Wiederholungsversuche | Grund und Anzahl der Versuche bei einem Fehler. |
| Empfangen am / Verarbeitet am | Zeitstempel des Empfangs bzw. der Verarbeitung. |
| Shop-Code | Shop, von dem das Event kam. |
| Aktion | Beschreibung |
|---|---|
| Jetzt verarbeiten | Verarbeitet alle ausstehenden Events sofort. |
| Fehlgeschlagene erneut verarbeiten | Setzt alle fehlgeschlagenen Events auf ausstehend zurück, damit sie erneut verarbeitet werden. |
| Verarbeitete löschen | Löscht alle erfolgreich verarbeiteten Events, die älter als 7 Tage sind. |
Hinweise
Azure Function als Endpunkt
Webhooks benötigen einen öffentlich erreichbaren HTTPS-Endpunkt. Es empfiehlt sich eine Azure Function, die eingehende Events entgegennimmt und in die Business-Central-Work-Queue weiterleitet.
HMAC-Signaturprüfung
Shopware signiert Webhook-Payloads mit einem HMAC-Secret. Die Azure Function sollte die Signatur validieren, um manipulierte Requests abzulehnen.
- Webhooks ergänzen die reguläre Job-Queue-basierte Synchronisation — sie ersetzen sie nicht.
- Bei Ausfall des Webhook-Endpunkts greift die Job Queue als Fallback.
- Nicht alle Shop-Events sind für BC relevant — konfigurieren Sie nur die benötigten Events.