Webhooks

Webhooks verbinden Shop-Ereignisse mit externen Systemen und zeigen im Logbuch, ob Versandjobs erfolgreich, ausstehend oder fehlgeschlagen sind.

Voraussetzungen und Reiter

Die Webhook-Verwaltung besteht aus den Reitern Einstellungen und Logbuch.

• Rechtepruefung: Ohne Webhook-Recht wird die Seite nicht ausgegeben.
• App-Pruefung: Ist die REST-API-App nicht aktiv, zeigt das Backend einen Setup-Hinweis.
• Einstellungen: enthaelt das Webhook-Passwort, die Webhookliste sowie Erstellen, Bearbeiten und Loeschen von Ziel-URLs.
• Logbuch: zeigt erzeugte Webhook-Jobs, Statusfarben, HTTP-Ergebnisse, Zieladressen, Versuche und Detaildaten.

Webhook-Passwort

Das Formular webhooksetup speichert das Feld webhook_passwort in der Konfiguration. Das Passwort kann fuer Basic Authorization beim Versand genutzt werden.

• webhook_passwort: Passwortwert fuer Webhook-Authentifizierung.
• Standard-Benutzer: Bei normalen Bestellungen kann der Benutzername apt-shop verwendet werden.
• Dropship-Bestellungen: Wenn bei der Bestellerstellung ein Webhook-Passwort vorhanden ist und es sich um eine Dropship-Bestellung handelt, kann die Dropshipper-ID als Benutzername genutzt werden.
• Speichern: Nach dem Speichern wird zur Webhookseite zurueckgeleitet und eine Erfolgsmeldung angezeigt.

Webhookliste

Die Webhookliste ist eine konfigurierbare BsTable. Ein separates Filterformular ist nicht vorhanden; die Tabellensuche kann sichtbare Werte wie Bezeichnung, Grund oder URL durchsuchen.

• ID: interne Webhook-ID; auf kleinen Ansichten ausgeblendet.
• Bezeichnung: zeigt den lesbaren Namen des Typs und den technischen Wert aus type.
• Grund: zeigt den lesbaren Namen des Ereignisgrundes und den technischen Wert aus reason; auf kleinen Ansichten ausgeblendet.
• URL: zeigt die Zieladresse aus url; auf kleinen Ansichten ausgeblendet.
• Statusfarbe: aktive Webhooks erhalten eine aktive Zeilenklasse, inaktive Webhooks eine inaktive Zeilenklasse.
• Optionen: enthaelt Bearbeiten und Loeschen, solange die REST-API-App aktiv ist. Die Spalte ist zentriert und nicht sortierbar.

Webhook erstellen und bearbeiten

Ueber Webhook erstellen oder die Bearbeiten-Aktion oeffnet sich ein grosser Dialog. Neue Webhooks waehlen eine Aktion aus der Backendliste; bestehende Webhooks behalten die gespeicherte Aktion und zeigen diese nur noch als Text.

• status: Checkbox fuer aktiv oder inaktiv. Neue Webhook-Objekte starten aktiv. Fehlt der Checkboxwert beim Speichern, setzt das Backend den Status auf 0.
• datatyp: Auswahl aus Typ und Grund im Format type|reason. Bei neuen Webhooks wird diese Auswahl aus den verfuegbaren Ereignissen aufgebaut und alphabetisch nach Anzeige-Label sortiert.
• type: technischer Ereignisbereich, zum Beispiel Bestellung, Kunde, Rechnung, Newsletteranmeldung, Hersteller, Lieferant, Verfuegbarkeit, Einheit, Steuersatz, Lager, Waehrung oder Produkt.
• reason: technischer Anlass innerhalb des Bereichs, zum Beispiel Erstellung, Aktualisierung, Loeschung, Statuswechsel, Versand, Teilversand, Storno, Retoure oder Bestandsaenderung.
• url: Zieladresse, an die Jobs fuer diesen Webhook gesendet werden.

Beim Speichern trennt das Backend datatyp in type und reason, speichert die Felder und schliesst den Dialog mit Erfolgsmeldung.

Webhook-Ereignisse und Versand

Der Versandmanager sucht aktive Webhooks passend zu type und reason. Nur Datensaetze mit status 1 werden fuer Ereignisse herangezogen.

• Bestellungen: unterstuetzen unter anderem Statuswechsel, Erstellung, Loeschung, Versand, Teilversand, Storno, Teilstorno, Retoure und Teilretoure.
• Kunden: unterstuetzen Erstellung, Aktualisierung und Loeschung.
• Rechnungen: unterstuetzen Erstellung und Loeschung.
• Newsletteranmeldungen: unterstuetzen Erstellung.
• Stammdaten: Hersteller, Lieferant, Verfuegbarkeit, Verpackungseinheit, Steuersatz, Lager und Waehrung unterstuetzen Erstellung, Aktualisierung und Loeschung.
• Produkte: der Produktbereich unterstuetzt Bestandsaenderungen.
• Payload: Je nach Ereignis werden Daten aus den passenden API-v2-Controllern in die Jobdaten uebernommen.

Logbuch, Suche und Tabelle

Das Logbuch verwendet einen Datenfilter mit maximal 1000 Ergebnissen und eine konfigurierbare BsTable fuer Webhook-Jobs. Die Suche nutzt einen Volltextindex ueber event, url, payload_json und status.

• Suche: Suchbegriffe werden in einzelne Woerter zerlegt und gegen Event, Zieladresse, Payload und Status gesucht.
• Aktive Filter: Wenn eine Suche keine Treffer liefert und aktive Filter vorhanden sind, kann das Backend einen Reset-Hinweis anzeigen.
• Checkbox: waehlt Jobs fuer Sammelaktionen aus.
• ID: interne Job-ID; auf kleinen Ansichten ausgeblendet.
• Datum: zeigt updated_at und ist die Standardsortierung absteigend.
• Event: zeigt den Ereignisnamen aus event.
• Status: zeigt status; sucess wird aktiv, pending warnend und failed inaktiv eingefarbt.
• HTTP-Code: zeigt http_code; auf kleinen Ansichten ausgeblendet.
• Ziel-URL: zeigt url; auf kleinen Ansichten ausgeblendet.
• Versuche: zeigt try_count; auf kleinen Ansichten ausgeblendet.
• Optionen: enthaelt Details und Loeschen. Die Spalte ist zentriert und nicht sortierbar.

Sammelaktionen und Details

Ausgewaehlte Logbuch-Jobs koennen gesammelt erneut versendet oder geloescht werden.

• Erneut versenden: oeffnet einen Bestaetigungsdialog. Optional kann new_url gesetzt werden. Beim Ausfuehren setzt das Backend die Ziel-URL bei Bedarf neu, stellt status auf pending, setzt try_count auf 0 und speichert den Job.
• Loeschen: oeffnet einen Bestaetigungsdialog und entfernt die ausgewaehlten Jobs.
• Einzelnes Loeschen: die Tabellenoption entfernt genau den gewaehlten Job und leitet ins Logbuch zurueck.
• Details: zeigt Status, Event, formatiertes Payload-JSON, Header-JSON, Response Body und Fehlermeldung. Kaputtes oder leeres JSON wird roh beziehungsweise als leerer Wert angezeigt.
• Weiterleitung: Nach Sammelaktionen leitet das Backend wieder ins Webhook-Logbuch.