Webhook-Aufruf durch einen Auslöser

Aktualisiert 2026-07-17

Hinweis: Dies ist ein hoch technischer Artikel. Daher empfehlen wir, Ihre IT‑Abteilung beim Lesen hinzuzuziehen. Sollten Sie Fragen oder Anliegen haben, kontaktieren Sie uns bitte über support@azumuta.com – wir helfen Ihnen gerne weiter.

Wenn Azumuta ein anderes System darüber informieren muss, dass etwas passiert ist (z. B. eine Produktbestellung abgeschlossen wurde oder ein Problem gemeldet wurde), verwenden Sie vorzugsweise einen Webhook-Trigger statt die REST API periodisch abzufragen. Webhooks übertragen nur die benötigten Daten zum Zeitpunkt des Ereignisses. Für das umfassendere Muster der ERP‑Integration siehe ERP Integration.

Dieser Artikel erläutert, wie Sie einen Call a webhook-Trigger konfigurieren: wo Sie ihn einrichten, welche Attribute auszufüllen sind und was Azumuta an Ihren Endpunkt sendet.

Voraussetzungen

Webhook-Trigger enthalten einen apiKey, der von einem Api Device in Ihrem Workspace stammt. Sie benötigen mindestens ein konfiguriertes Api Device. Falls keines vorhanden ist, schlägt der Webhook mit einer Fehlermeldung fehl, z. B. No api device configured.

Siehe So erstellen und verwalten Sie API-Schlüssel für Informationen zur Einrichtung eines Api Device und Azumutas REST API dafür, wie dieser Schlüssel beim Zurückaufruf von Azumuta verwendet wird.

So fügen Sie einen Webhook-Trigger hinzu

Klicken Sie auf “Settings” unter “Management”.
Klicken Sie auf “Triggers” unter “Integrations”.
Klicken Sie auf “Add trigger” (der gelbe Plus‑Button).
Füllen Sie die unten beschriebenen Felder aus.
Wenn Sie fertig sind, klicken Sie auf “Add”.

Was, Wann und Geltungsbereich

What: Wählen Sie „Call a webhook“.
When: Wählen Sie das Ereignis, das den Trigger auslösen soll (z. B. wenn eine Produktbestellung abgeschlossen ist oder ein Problem gemeldet wurde). Verfügbare Ereignisse hängen vom Geltungsbereich ab.
Scope: Wählen Sie, wofür der Trigger gilt – z. B. eine Artikelkategorie, alle Produktbestellungen, Probleme, Audits oder ein Board. Verfügbare Ereignisse hängen vom Geltungsbereich ab. Siehe:

Sie können den Trigger später bearbeiten oder löschen und die Nutzungshistorie einsehen.

Attribute

Nachdem Sie What und When ausgewählt haben, zeigt der Abschnitt Attributes die Webhook‑Optionen an:

Endpoint: Die HTTPS‑URL, die Azumuta aufruft (Platzhalter beginnt mit https://). Dieser Endpunkt muss von den Azumuta‑Servern erreichbar sein.
Method: Radio‑Buttons für GET oder POST. Standard ist GET.
Payload: Wird nur angezeigt, wenn die Methode POST ist. Tragen Sie hier den benutzerdefinierten Body‑Inhalt ein. Die UI‑Hinweis lautet: “You can use parameters in this field.”

Was Azumuta sendet

Azumuta schickt immer einen apiKey von einem Workspace‑Api Device sowie ereignisspezifische Felder:

Geltungsbereich	Typische Felder
Product orders	`identifier` (Produktauftragsnummer) und, falls zutreffend, `workinstructionId` und `recordingId`
Issues	`issueId`, `issueNumber` (und bei einigen Ereignissen verwandte Spalten-/Aktionsfelder)
Audits	`recordingId`, `workinstructionId` und verwandte Audit‑Felder wie `auditNumber`

Wie diese Felder übermittelt werden, hängt von der Methode ab:

GET: Felder werden als URL‑Query‑Parameter angehängt.
POST: Felder werden als JSON im Request‑Body gesendet. Wenn Sie eine benutzerdefinierte Payload konfiguriert haben, wird dieser Inhalt im JSON‑Body unter dem Schlüssel payload verschachtelt (neben apiKey und den oben genannten Ereignisfeldern).

Ihr empfangendes System kann den enthaltenen apiKey verwenden, um bei Bedarf zusätzliche Daten über die Azumutas REST API abzurufen – ein häufiges Muster mit einer Integrationsschicht vor einem ERP.