> For the complete documentation index, see [llms.txt](https://helpcenter.etron.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://helpcenter.etron.info/verwaltungsoberflache/api-and-hooks/webhooks.md).
# Webhooks
Webhooks, HTTP-Callbacks, Actions, Automations, Schedules, Webhook-Protokollierung
{% hint style="success" %}
*Modul: ETRON onRetail REST API*
{% endhint %}
> *API & Hooks -> Webhooks*
Webhooks sind HTTP-Callbacks für ausgehende Anfragen Webhooks melden Datenbankereignisse aktiv an externe Systeme. Ziel-URL, Nutzlast, Header und Authentifizierung werden je Webhook konfiguriert. Bei einem definierten Ereignis wird eine Anfrage an eine hinterlegte Ziel-URL gesendet.
## Einsatzbereiche
Webhooks können für folgende Vorgänge eingesetzt werden:
* Neue oder geänderte Datensätze werden an ein anderes System übergeben.
* Externe Prozesse werden bei Statusänderungen ausgelöst.
* Ausgewählte Daten werden zeitgesteuert exportiert oder manuell nachgesendet.
## Auslöserarten
Die Auslösung kann über Actions, Automations oder Schedules erfolgen. Ziel-URL, HTTP-Methode, Header, Nutzlast, Authentifizierung und Antwortverarbeitung werden für alle Auslöserarten gleich konfiguriert.
* **Actions** werden manuell über das Aktionsmenü eines Datensatzes ausgelöst.
* **Automations** werden beim Anlegen, Ändern oder Löschen automatisch ausgelöst.
* **Schedules** werden zeitgesteuert durch einen Cron-Job ausgeführt.
{% hint style="warning" %}
*Für Webhooks ist keine Queue vorhanden. Fehlgeschlagene Anfragen werden nicht automatisch wiederholt. Für kritische Integrationen muss die Protokollierung regelmäßig überwacht werden.*
{% endhint %}
## Actions
> *API & Hooks → Webhooks → Actions*
Erstellung eines Action-Webhooks
Actions werden manuell aus dem Aktionsmenü eines Datensatzes ausgelöst. Sie können in Listen- und Formularansichten bereitgestellt werden.
### Einsatzbereiche
* Einzelne Datensätze können nach einem Fehler erneut gesendet werden.
* Ad-hoc-Übergaben können gezielt ausgelöst werden.
* In Listenansichten können mehrere Datensätze verarbeitet werden.
* Neue Konfigurationen können vor der Automation getestet werden.
### Grundeinstellungen
#### **Name der Aktion**
Die interne Bezeichnung wird in Auswahllisten und Protokollen angezeigt.
#### **Modell**
Das Modell der verarbeiteten Datensätze wird ausgewählt, beispielsweise `res.partner` oder `sale.order`.
#### **Aktiv**
Bei Deaktivierung wird keine Anfrage ausgelöst. Die Konfiguration bleibt erhalten.
#### Im Batch ausführen
Bei Aktivierung werden mehrere Datensätze in einer Anfrage gebündelt übergeben. Andernfalls wird je Datensatz eine Anfrage gesendet.
#### Post Commit
Bei Aktivierung wird die Anfrage nach dem Datenbank-Commit versendet. Zurückgerollte Transaktionen lösen damit keinen Webhook aus.
#### Sichtbar in
Die Bereitstellung in Listen- und Formularansicht wird festgelegt.
#### Sicherheit, Berechtigungsgruppen
Die Sichtbarkeit wird auf definierte Gruppen beschränkt.
#### Bestätigung erforderlich
Vor der Ausführung wird ein Bestätigungsdialog eingeblendet.
#### Request
**Address (URL)**
Der Ziel-Endpunkt des empfangenden Systems wird hinterlegt.
**Method**
`GET`, `POST`, `PUT`, `PATCH` oder `DELETE` kann ausgewählt werden.
**Timeout**
Die maximale Wartezeit auf eine Antwort des Zielsystems wird festgelegt.
#### Apply Authentication
{% hint style="info" %}
*Der Reiter Authentication wird nach Aktivierung der Einstellung Apply Authentication angezeigt.*
{% endhint %}
Eine optionale Referenz auf eine [Authentifizierung](/verwaltungsoberflache/api-and-hooks/authentication.md) kann hinterlegt werden.
#### Fetch CSRF Token
{% hint style="info" %}
*Der Reiter CSRF Token wird nach Aktivierung der Einstellung Fetch CSRF Token angezeigt.*
{% endhint %}
Vor der Hauptanfrage wird ein CSRF-Token vom Zielsystem bezogen. Der Token wird in die Hauptanfrage übernommen.
#### Adapt Headers
{% hint style="info" %}
*Der Reiter Header Values wird nach Aktivierung der Einstellung Adapt Headers angezeigt.*
{% endhint %}
Individuelle HTTP-Header können pro Webhook mit statischen oder dynamischen Werten hinterlegt werden.
#### Adapt Payload (Payload anpassen)
{% hint style="info" %}
*Der Reiter Adapt Payload wird nach Aktivierung der Einstellung Adapt Payload angezeigt.*
{% endhint %}
Im Reiter *Adapt Payload* kann die Nutzlast per Python-Code angepasst werden. `record` enthält den auslösenden Datensatz. Bei Batch-Ausführung wird `records` bereitgestellt. `env` ermöglicht den Zugriff auf die Odoo-Umgebung. `payload` und `headers` enthalten die vorbereiteten Daten.
```python
payload.update({
"external_id": record.id,
"name": record.name,
"email": record.email,
})
headers["X-Source"] = "onRetail"
```
#### Process Response (Antwort verarbeiten)
{% hint style="info" %}
*Der Reiter Process Response wird nach Aktivierung der Einstellung Process Response angezeigt.*
{% endhint %}
Im Reiter *Process Response* kann die Antwort des Zielsystems ausgewertet werden. Dadurch kann beispielsweise eine externe ID gespeichert werden. `response`, `record` und `env` stehen zur Verfügung.
#### Vorschau
Über *Vorschau* kann ein Webhook mit einem Datensatz getestet werden.
* **Nur Payload aufbauen** zeigt die berechnete Nutzlast ohne Anfrage.
* **Anfrage tatsächlich senden** führt den vollständigen Webhook aus. Änderungen aus *Process Response* bleiben gespeichert.
Zur Ausführung werden ein oder mehrere Datensätze ausgewählt. Anschließend wird **Aktion -> \[Name des Webhooks]** aufgerufen. Ergebnis und Antwort werden im Protokoll erfasst.
## Automations
> *API & Hooks → Webhooks → Automations*
Erstellung eines Automation-Webhooks
Automations werden bei definierten Ereignissen eines Modells ausgelöst. Sie eignen sich für Echtzeit-Integrationen.
### Grundeinstellungen
#### Name der Aktion
Die interne Bezeichnung wird in Auswahllisten und Protokollen angezeigt.
#### Modell
Das Modell der verarbeiteten Datensätze wird ausgewählt, beispielsweise `res.partner` oder `sale.order`.
#### Aktiv
Bei Deaktivierung wird keine Anfrage ausgelöst. Die Konfiguration bleibt erhalten.
#### Im Batch ausführen
Bei Aktivierung werden Ereignisse in einer Anfrage gebündelt übergeben.
#### Post Commit
Die Anfrage wird nach dem Datenbank-Commit gesendet. Zurückgerollte Transaktionen lösen damit keinen Webhook aus.
#### Import
Über *Import* kann eine bestehende Automation als Vorlage übernommen werden.
#### Trigger-Typen
**Beim Erstellen**
Die Auslösung erfolgt beim Anlegen eines neuen Datensatzes.
**Beim Aktualisieren**
Die Auslösung erfolgt beim Ändern eines Datensatzes. Sie kann auf Felder oder Wertewechsel begrenzt werden.
**Beim Erstellen und Aktualisieren**
Die Auslösung erfolgt beim Anlegen oder Ändern eines Datensatzes.
**Beim Löschen**
Die Auslösung erfolgt beim Löschen eines Datensatzes.
**Auf Basis zeitlicher Bedingungen**
Die Auslösung erfolgt relativ zu einem Datumsfeld. Die Prüfung wird über einen Cron ausgeführt.
#### Bedingungen und Einstellungen
**Anwenden auf**
Die Auslösung kann auf passende Datensätze begrenzt werden. Beispielsweise können Aufträge mit `state = 'sale'` übergeben werden.
**Ausgelöst durch**
Ereignisse können auf bestimmte Benutzer oder Gruppen beschränkt werden.
**Ignorieren bei Massenoperationen**
Bei Bulk-Imports oder Migrationsläufen kann die Ausführung unterdrückt werden.
**Reihenfolge**
Die Ausführungsreihenfolge mehrerer Automations wird festgelegt.
#### Request
**Address (URL)**
Der Ziel-Endpunkt des empfangenden Systems wird hinterlegt.
**Method**
`GET`, `POST`, `PUT`, `PATCH` oder `DELETE` kann ausgewählt werden.
**Timeout**
Die maximale Wartezeit auf eine Antwort des Zielsystems wird festgelegt.
{% hint style="warning" %}
*Automations werden innerhalb der auslösenden Transaktion ausgeführt. Ein langsames Zielsystem verzögert daher den Vorgang in ETRON onRetail. Ein kurzer Timeout wird empfohlen.*
{% endhint %}
#### Apply Authentication
{% hint style="info" %}
*Der Reiter Authentication wird nach Aktivierung der Einstellung Apply Authentication angezeigt.*
{% endhint %}
Eine optionale Referenz auf eine [Authentifizierung](/verwaltungsoberflache/api-and-hooks/authentication.md) kann hinterlegt werden.
#### Fetch CSRF Token
{% hint style="info" %}
*Der Reiter CSRF Token wird nach Aktivierung der Einstellung Fetch CSRF Token angezeigt.*
{% endhint %}
Vor der Hauptanfrage wird ein CSRF-Token vom Zielsystem bezogen. Der Token wird in die Hauptanfrage übernommen.
#### Adapt Headers
{% hint style="info" %}
*Der Reiter Header Values wird nach Aktivierung der Einstellung Adapt Headers angezeigt.*
{% endhint %}
Individuelle HTTP-Header können pro Webhook hinterlegt werden.
#### Adapt Payload
{% hint style="info" %}
*Der Reiter Adapt Payload wird nach Aktivierung der Einstellung Adapt Payload angezeigt.*
{% endhint %}
Im Reiter *Adapt Payload* kann die Nutzlast per Python-Code angepasst werden. `record` enthält den auslösenden Datensatz. `env`, `payload` und `headers` stehen zur Verfügung.
#### Process Response
{% hint style="info" %}
*Der Reiter Process Response wird nach Aktivierung der Einstellung Process Response angezeigt.*
{% endhint %}
Im Reiter *Process Response* kann die Antwort des Zielsystems ausgewertet werden.
#### Vorschau
Über *Vorschau* kann eine Automation getestet werden.
## Schedules
> *API & Hooks → Webhooks → Schedules*
Erstellung eines Schedule-Webhooks
Schedules werden zeitgesteuert durch einen Cron-Job ausgeführt. Bei jedem Lauf werden die passenden Datensätze anhand einer Domäne ermittelt und verarbeitet.
### Einsatzbereiche
* Regelmäßige Exporte können zeitgesteuert durchgeführt werden.
* Batch-Übergaben können für Zielsysteme ohne Echtzeitverarbeitung bereitgestellt werden.
* Wiederkehrende Statusabfragen können geplant werden.
### Grundeinstellungen
#### Name der Aktion
Die interne Bezeichnung wird in Auswahllisten und Protokollen angezeigt.
#### Modell
Das Modell der verarbeiteten Datensätze wird ausgewählt, beispielsweise `res.partner` oder `sale.order`.
#### Aktiv
Bei Deaktivierung wird der Zeitplan nicht ausgeführt. Die Konfiguration bleibt erhalten.
#### Im Batch ausführen
Bei Aktivierung werden alle Datensätze eines Laufs in einer Anfrage gebündelt übergeben.
#### Post Commit
Die Anfrage wird nach dem Datenbank-Commit gesendet.
#### Zeitplaner-Benutzer
Der Benutzer für die Ausführung wird festgelegt. Dessen Berechtigungen und Sichtbarkeiten werden angewendet.
#### Zeitplan
**Ausführen alle (Intervall)**
Die Ausführungshäufigkeit wird in Minuten, Stunden, Tagen, Wochen oder Monaten festgelegt.
{% hint style="warning" %}
*Kurze Intervalle können ETRON onRetail und das Zielsystem belasten.*
{% endhint %}
**Nächstes Ausführungsdatum**
Der Zeitpunkt der nächsten geplanten Ausführung wird angezeigt.
**Anzahl der Aufrufe**
Die verbleibende Anzahl der Ausführungen wird festgelegt. `-1` bedeutet unbegrenzt.
**Priorität**
Die Reihenfolge gegenüber anderen Cron-Aufgaben wird gesteuert. Kleinere Werte werden zuerst ausgeführt.
**Wiederholung versäumt**
Bei Aktivierung werden versäumte Läufe beim nächsten Start nachgeholt. Andernfalls wird nur die nächste reguläre Ausführung berücksichtigt.
#### Datensatzauswahl
**Anwenden auf**
Eine Domäne legt die pro Lauf verarbeiteten Datensätze fest.
**Verarbeitung**
Eine Anfrage je Datensatz oder eine aggregierte Anfrage für alle Treffer wird festgelegt.
**Sicherheit, Berechtigungsgruppen**
Die Sichtbarkeit wird auf definierte Gruppen beschränkt.
#### Request
**Address (URL)**
Der Ziel-Endpunkt des empfangenden Systems wird hinterlegt.
**Method**
`GET`, `POST`, `PUT`, `PATCH` oder `DELETE` kann ausgewählt werden.
**Timeout**
Die maximale Wartezeit auf eine Antwort des Zielsystems wird festgelegt.
#### Apply Authentication
{% hint style="info" %}
*Der Reiter Authentication wird nach Aktivierung der Einstellung Apply Authentication angezeigt.*
{% endhint %}
Eine optionale Referenz auf eine [Authentifizierung](/verwaltungsoberflache/api-and-hooks/authentication.md) kann hinterlegt werden.
#### Fetch CSRF Token
{% hint style="info" %}
*Der Reiter CSRF Token wird nach Aktivierung der Einstellung Fetch CSRF Token angezeigt.*
{% endhint %}
Vor der Hauptanfrage wird ein CSRF-Token vom Zielsystem bezogen. Der Token wird in die Hauptanfrage übernommen.
#### Adapt Headers
{% hint style="info" %}
*Der Reiter Header Values wird nach Aktivierung der Einstellung Adapt Headers angezeigt.*
{% endhint %}
Individuelle HTTP-Header können pro Zeitplan hinterlegt werden.
#### Adapt Payload
{% hint style="info" %}
*Der Reiter Adapt Payload wird nach Aktivierung der Einstellung Adapt Payload angezeigt.*
{% endhint %}
Im Reiter *Adapt Payload* kann die Nutzlast per Python-Code angepasst werden. Bei Einzelverarbeitung steht `record` bereit. Bei aggregierter Verarbeitung wird `records` bereitgestellt. `env`, `payload` und `headers` stehen zur Verfügung.
#### Process Response
{% hint style="info" %}
*Der Reiter Process Response wird nach Aktivierung der Einstellung Process Response angezeigt.*
{% endhint %}
Im Reiter *Process Response* kann die Antwort des Zielsystems ausgewertet werden. `response`, `record` beziehungsweise `records` und `env` stehen zur Verfügung.
#### Vorschau
Über *Vorschau* kann ein Zeitplan mit der aktuellen Domäne getestet werden. Das Intervall muss dafür nicht abgewartet werden.
## Protokollierung und Auswertung
Jeder Webhook-Aufruf wird unabhängig von der Auslöserart protokolliert. Fehlgeschlagene Aufrufe können aus einem Protokolleintrag erneut gesendet werden. Dabei werden Datensatz und Konfiguration erneut ausgewertet.
**Weitere Informationen:**\
[Webhook-Protokollierung](/verwaltungsoberflache/api-and-hooks/protokollierung/webhooks.md)
## Best Practices
* Neue Webhooks werden zunächst über *Vorschau* getestet.
* Für Automations wird ein kurzer Timeout definiert.
* Zu jeder Automation wird eine gleichnamige Action zum Nachsenden eingerichtet.
* Domänen werden präzise definiert und Fehlerquoten regelmäßig geprüft.
* *Fetch CSRF Token* wird nur bei erzwungenem CSRF-Schutz aktiviert. Der Vorabruf verdoppelt sonst die HTTP-Anfragen.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://helpcenter.etron.info/verwaltungsoberflache/api-and-hooks/webhooks.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
