Zu Content springen
Deutsch
  • Es gibt keine Vorschläge, da das Suchfeld leer ist.

Webhooks anwenden und konfigurieren

Automatisierter Datenaustausch zwischen dem KI-Chatbot und externen Systemen zur Optimierung von Serviceprozessen

Webhooks ermöglichen die Kommunikation zwischen verschiedenen Anwendungen in Echtzeit. Dabei sendet ein Server (Absender) automatisch eine HTTP-Anfrage an einen anderen Server (Empfänger). Im Kontext von moinAI bedeutet dies, dass im Chat erhobene Daten an ein externes System übermittelt oder Informationen von dort abgerufen werden, um sie den Nutzer:innen direkt im Chat-Widget anzuzeigen.

Voraussetzungen für die Einsatz eines Webhooks sind ein bereits aufgesetztes Formular oder ein KI-Agent im Hub und eine ereichbare Ziel-URL (API-Endpunkt) des externen Systems.

  1. Nutzen und Funktionsweise
  2. Webhook erstellen
    2.1 Technische Gestaltung
    2.2 Erweiterte Optionen (Cookies & Authentifizierung)
    2.3 Webhook-Aktionen vor der Ausführung
  3. Verwendung im Chatbot
    3.1 Webhooks als KI-Aktion
    3.2 Webhooks in Formularen
  4. Testen und Validierung
  5. Praxisbeispiele

 

1. Nutzen und Funktionsweise

Der Einsatz von Webhooks erlaubt es, den KI-Chatbot nahtlos mit Drittanbieter-Systemen wie z. B. CRM-Tools, Produktdatenbanken und Shopsysteme zu verbinden. Dies schafft folgende Vorteile:

  • Automatisierung: Prozesse wie Terminbuchungen oder Bestellstatus-Abfragen erfolgen unmittelbar im Dialog, wodurch fallabschließende Unterhaltungen ermöglicht werden
  • Flexibilität: Beliebige REST-Webhooks können ohne Code-Anpassungen integriert werden.
  • Kontextbezug: Informationen aus der laufenden Unterhaltung fließen direkt in die API-Abfrage ein, z. B. Kundenstatus, aktuelle Unterseite oder Produktinteresse.

➔ Funktionsweise von Webhooks einfach erklärt: Die Post-Analogie 📩🏷️📯 (zum Ausklappen klicken)

Zur Veranschaulichung der technischen Abläufe dient der Vergleich mit einer Hotelrezeption und dem Postwesen.

📯 Der Webhook: Die Vermittlungsstelle

Der KI-Chatbot fungiert in dieser Analogie als Vermittlungsstelle, vergleichbar mit einer Hotelrezeption. Tritt eine Nutzer:in mit einem Anliegen (z. B. der Frage nach einem Paketstatus) an den Chatbot heran, verfügt dieser nicht über das notwendige Wissen im eigenen Speicher. Ein Webhook agiert hier wie eine digitale Rohrpost oder ein direkter Anruf an das Lager (Backend oder Shopsystem). Die notwendigen Daten werden übermittelt, dort geprüft und die Antwort unmittelbar an den Chatbot zurückgesendet, um die Nutzer:in zu informieren.

📩 Der Body: Der Briefinhalt

Während die URL lediglich die Adresse des Empfängers angibt, repräsentiert der Body das eigentliche Schreiben im Inneren des Briefes. Hier sind die spezifischen Details hinterlegt, die das Zielsystem zur Bearbeitung benötigt (z. B. Kundennummer oder Zählerstand).

  • Default (Standard): Default (Standard): Zeitsparende Bündelung und Übertragung sämtlicher Informationen einer Unterhaltung in einem Paket. Wegen häufigem Datenüberschuss und nicht passenden Formaten wird von der Nutzung bei POST-Methoden abgeraten, da Schnittstellen (APIs) exakte Datenstrukturen voraussetzen.
  • Custom (Individuell): Vergleichbar mit einem leeren Blatt Papier, auf dem ausschließlich die benötigten Informationen im exakt geforderten Format notiert werden. Dies sorgt für eine präzise und effiziente Datenübermittlung.

🏷️ Die Headers: Der Briefumschlag

Die Headers entsprechen den Informationen auf dem Briefumschlag sowie den Anweisungen für das Zustellpersonal. Sie regeln die Rahmenbedingungen, damit der Inhalt (Body) sicher und korrekt verarbeitet wird:

  • Zustellanweisung (Authorization): Fungiert wie ein Identitätsnachweis oder ein Stempel für ein „Einschreiben". Mit dem Header Authorization und einem Sicherheitsticket (z. B. einem JWT) weist sich der Chatbot als autorisierter Absender aus.
  • Sprachfestlegung (Content-Type): Informiert das Empfängersystem über das verwendete Format. Die Angabe application/json signalisiert beispielsweise, dass der Inhalt in einer spezifischen technischen Sprache verfasst wurde.
  • Spezielle Etiketten (Custom Headers): Entsprechen individuellen Kennzeichnungen wie einem X-Api-Key. Fehlen diese notwendigen Markierungen, wird der „Brief" vom Zielsystem aus Sicherheitsgründen nicht geöffnet.

Begriff

Analogie

Zweck

Webhook

Rohrpost / Anruf

Der Weg des Datenaustauschs

Body

Briefinhalt

Die eigentliche Information (Daten)

Header

Briefumschlag

Sicherheit und Rahmenbedingungen

Infografik zum moin.ai Datenfluss: Der User Input wird an den moin.ai Hub geleitet. Dieser kommuniziert über einen Webhook mit einem externen Backend, erhält eine Response und gibt daraufhin das Chatbot-Ergebnis aus.

Anwendungsbeispiel: Fahrzeitenabfrage per Webhook im Chat (Video)

 

2. Webhook erstellen

  1. Der Zugriff auf die Übersicht erfolgt im Hub über den Menüpunkt Integrationen → Webhooks (Push).
  2. Mit der Schaltfläche Bearbeiten öffnet sich die Liste der bestehenden Webhooks.
  3. Über den Button Webhook erstellen lässt sich eine neue, leere Maske öffnen.

  4. Bestehende Webhooks können über das Stift-Symbol angepasst werden.
  5. Mit einem Klick auf den Button Veröffentlichen unten/oben rechts im Webhook-Editor ist der Webhook in der Preview und Live verfügbar und kann mit KI-Agenten oder Formularen verknüpft werden.

2.1 Technische Gestaltung

In der Editier-Ansicht werden die Basisdaten der Schnittstelle festgelegt.

  1. Namen auswählen: Ein individuell gewählter Name, der zur internen Unterscheidung im Hub dient. Der Name kann problemlos jederzeit geändert werden.
  2. Kontextnamen bestimmen: Unter diesem Namen wird die Antwort der API im Dialog gespeichert. Die Verwendung des Kontextnamen andernorts als Verweis, z. B. über Handlebars, ist ebenfalls möglich. Aus diesem Grund sollte der Name möglichst konstant bleiben, da sonst jede Verknüpfung eine manuelle Anpassung benötigt.
  3. Ziel-URL eintragen: Die API-Adresse, an welche die Daten gesendet werden. Es kann sich um eine interne oder externe API handeln. Auch hier können Handlebars genutzt werden, sodass die URL nicht starr ist, sondern dynamisch genutzt werden kann.
  4. Methode festlegen: Festlegung der HTTP-Methode, nach welcher der Webhook die Daten sendet. Standardmäßig wird POST zum Senden von Daten oder GET zum Abfragen genutzt.

Dynamische Platzhalter (Handlebars)

Handlebars (die geschweiften Klammern {{...}}) fungieren als dynamische Platzhalter. Im Hub wird so festgelegt, an welcher Stelle der Chatbot eine Information einsetzen soll, die erst im Moment des Gesprächs von Nutzer:innen erzeugt wird.

Beispielsweise können durch Handlebars-Vorlagen Werte aus dem Dialogkontext dynamisch in die Ziel-URL integriert werden.
Beispiel: https://api.beispiel.de/v1/orders/{{orderId}}/status. Hier wird orderId durch die tatsächliche Angabe der Nutzer:innen ersetzt.

2.2 Optional: Erweiterte Optionen (Cookies & Authentifizierung)

Für spezialisierte Anforderungen bietet der Editor zusätzliche Steuerungsmöglichkeiten:

  • Headers anpassen: Über Feld hinzufügen können benutzerdefinierte Header (z. B. content-type: application/json), die bei der Anfrage an die API übermittelt werden, hinterlegt werden. Alternativ kann über Vorlage verwenden ein Standard-Set geladen werden. Ein typisches Beispiel ist der X-Api-Key zur Authentifizierung der Anfrage. Hier ist die Konfiguration beliebig vieler Header möglich, um die Anforderungen der Ziel-API zu erfüllen.

  • Body: Es gibt die Optionen Default, Custom und No Body.

    • Default: Bei dieser Einstellung werden die zu versendenden Daten automatisch durch das Formular vorgegeben. Der KI-Chatbot übermittelt hierbei alle im aktuellen Formularschritt erhobenen Angaben als standardisiertes Datenpaket. Dies ist eine zeitsparende Lösung, sofern das Zielsystem die moinAI-Standardstruktur verarbeiten kann.

    • No Body: Diese Option wird gewählt, wenn für die Anfrage kein Nachrichteninhalt erforderlich ist. Dies ist der Standard für GET-Anfragen, bei denen Daten ausschließlich über die URL abgerufen werden.

    • Custom: Mit dieser Option ist die individuelle Gestaltung des Bodys möglich, sodass spezifische Daten an die API gesendet werden können. Dies ist besonders nützlich, wenn komplexere Datenstrukturen übertragen werden müssen. Die Konfiguration des Bodys erfolgt im JSON-Format. Mithilfe von Handlebars kann hierbei gezielt auf Informationen aus dem Dialogkontext zugegriffen werden, um dynamische Informationen wie Kundendaten oder Antworten zu integrieren.

  • Verwendung von Cookies: Durch Aktivierung dieser Option werden Cookies im Webhook-Request vom Zielsystem angenommen und verwendet. Dies ist vor allem relevant, um Sitzungen (Sessions) über den Webhook-Aufruf hinweg aufrechtzuerhalten. Datenschutzrechtlich ist zu prüfen, ob hierauf in den Datenschutzbestimmungen gesondert hingewiesen werden muss. Mehr zum Thema Datenschutz ist in diesem Artikel beschrieben.
  • Authentifizierung: Hier wird zwischen Keine Authentifizierung (Sicherheit erfolgt z. B. über API-Key im Header) und Basic Auth (Abfrage von Benutzername und Passwort) gewählt.

Sicherheit und Schutz vor Missbrauch (Empfehlung)

  1. API-Key und JWT: Die Nutzung eines API-Keys in Kombination mit einem JWT sorgt für eine zusätzliche Sicherheitsebene. Der API-Key wird im Header mitgesendet, während das JWT sicherstellt, dass die Anfrage authentifiziert ist und innerhalb einer bestimmten Zeitspanne erfolgt.
  2. TLS/SSL-Verschlüsselung: Alle Datenübertragungen sollten über HTTPS erfolgen, um sicherzustellen, dass die Daten während der Übertragung verschlüsselt sind und nicht von Dritten abgefangen werden können.

Jede Webhook-Konfiguration und API ist an einen spezifischen Anwendungsfall gebunden. Für unterschiedliche Funktionen (z. B. eine Produktsuche via Salesforce ProductSearch API und eine Ticket-Erstellung via Salesforce TicketAPI) ist die Einrichtung separater Webhooks erforderlich. Die Kombination mehrerer Webhooks innerhalb eines einzigen Formulars ist jedoch möglich.

JWT (JSON Web Token)

Ein JWT kann man sich wie ein digitales Festival-Bändchen vorstellen. Einmal erhalten, dient es für den Rest des Prozesses als Beweis, dass die Person bereits erfolgreich kontrolliert wurde.

2.3 Webhook-Aktionen vor der Ausführung

Optional können Aktionen aktiviert werden, die unmittelbar vor dem Absenden des Webhooks ausgeführt werden:

  • User Message History: Fügt den bisherigen Nachrichtenverlauf der Unterhaltung zum Kontext hinzu. Dies ist nützlich, wenn das Zielsystem (z. B. ein CRM) den gesamten Gesprächskontext für die weitere Bearbeitung benötigt.
  • Save File URL(s): Speichert die URLs von Dateien, die Nutzer:innen zuvor im Chat hochgeladen haben, im Kontext. Dies ist essenziell für Prozesse, bei denen Dokumente oder Bilder an ein Backend übertragen werden sollen.

Mit Klick auf das Fragezeichen öffnet sich ein Fenster mit weiterführenden Informationen zu den jeweiligen Webhook-Aktionen.

3. Verwendung im Chatbot

Nachdem ein Webhook konfiguriert wurde, kann er an verschiedenen Stellen im Chatbot eingesetzt werden.

3.1 Webhooks als KI-Aktion

KI-Aktionen ermöglichen es dem KI-Agenten, bei Bedarf selbstständig eine Abfrage zu starten.

  1. Unter Knowledge BaseRAG → in der Actions & Follow-Up Karte Add Action + wird eine neue Aktion erstellt.
  2. Die Verknüpfung erfolgt über die Auswahl des zuvor erstellten Webhooks unter Tool auswählen.
  3. Durch präzise Parameter-Beschreibungen weiß der KI-Agent, welche Informationen (z. B. eine ID) er vorab erfragen muss.

Mehr Informationen zu KI-Aktionen sind in diesem Artikel zu finden.

3.2 Webhooks in Formularen

In Formularen erfolgt die Integration an einer fest definierten Stelle im Abfragepfad.

  1. Im Formular-Editor wird an der gewünschten Stelle auf das Plus-Symbol geklickt.
  2. Aus der Element-Leiste wird Webhook ausgewählt.
  3. Im erscheinenden Feld wird der gewünschte Webhook ausgewählt.

Mehr Informationen zu Formularen finden sich in diesem Artikel.

 

4. Testen und Validierung

Um die korrekte Funktion sicherzustellen, sollte jede Konfiguration geprüft werden.

  1. Über den Button TESTEN oben rechts im Webhook-Editor wird die Test-Umgebung geöffnet.
  2. Ein Formular zur Simulation der Datenbasis wird ausgewählt.
  3. Mit TESTDATEN SENDEN wird die Anfrage ausgelöst und die Antwort der API validiert.

  4. Zusätzlich Validierung der Funktion in der Preview (für Webhooks in Formularen) oder im KI Playground (für Webhooks in KI-Aktionen). Im KI Playground wird detailliert angezeigt, wie eine KI-Aktion ausgeführt wurde.

5. Praxisbeispiele

Anwendungsfall

Methode

Nutzen

Bestellstatus

POST

Authentifiziert Nutzer:innen und gibt den aktuellen Lieferstatus aus.

Zählerstand

POST

Übermittelt erhobene Verbrauchsdaten sicher an das Backend des Dienstleisters.

Produktsuche

GET

Durchsucht externe Kataloge (z. B. Shopify) basierend auf Stichworten.

Seminarverfügbarkeit

GET

Prüft über eine Seminar-ID, ob noch Plätze frei sind und gibt die Antwort an den Chatbot zurück.

 

➔ Anleitung: Bestellstatus ermitteln (zum Ausklappen klicken)

Die Abfrage des Bestellstatus gehört zu den häufigsten Service-Anliegen im E-Commerce. Da Anfragen wie „Wo bleibt meine Bestellung?" einen großen Teil des Support-Volumens ausmachen, lässt sich durch die Nutzung eines Webhooks zur Anbindung des Shopsystems eine fallabschließende Antwort generieren. Diese informiert Nutzer:innen ohne manuelles Eingreifen des Kundenservice über den aktuellen Stand der Bestellung bzw. Lieferung. Da Nutzer:innen die Begriffe „Bestellstatus" und „Sendungsverfolgung" oft synonym verwenden, deckt dieses Beispiel beide Bereiche ab. Der Webhook geht an das Shopsystem, ruft den aktuellen Bestell- und Sendungsstatus ab und der KI-Chatbot gibt die Information passend aus.

Was benötigt wird:

  • 1x Formular zur Datenabfrage
  • 1x Zugriff auf die API des Shopsystems (z. B. Shopify, Shopware)
  • 1x Webhook für das Daten-Update zur Übermittlung des Bestellstatus; hat in diesem Beispiel den Kontextnamen order_status_response

Jedes Shopsystem gibt Daten in unterschiedlichen Formaten aus. Die hier gezeigten Code-Beispiele müssen daher an die spezifischen Variablenbezeichnungen des eigenen Systems angepasst werden.

1. Struktur des Abfrage-Prozesses

Um Informationen aus einem Shopsystem abzurufen, erfolgt die Identifikation der Bestellung in der Regel über zwei spezifische Angaben: die Bestellnummer und die E-Mail-Adresse. Der Prozess gliedert sich in folgende Schritte.

  1. Abfrage der Bestellnummer: Erhebung der eindeutigen Identifikationsnummer der Bestellung. Validierung mittels RegExp (Regular Expression) optional.
  2. Abfrage der E-Mail-Adresse: Zusätzliche Validierung zur Sicherstellung des Datenschutz-Standards inkl. E-Mail-Formatvalidierung.
  3. Ausführung des Webhooks: Übermittlung der Daten an das Shopsystem.
  4. Ausgabe der Antwort: Dynamische Erstellung der Nachricht basierend auf den vom System zurückgegebenen Werten.

2. Konfiguration des Webhooks

Für die Kommunikation mit dem Shopsystem wird im Bereich Integrationen → Webhooks (Push) ein neuer Webhook angelegt.

  • URL: https://api.dein-shopsystem.de/v1/orders/{{orderId}}/status
  • Methode: POST (oder GET, je nach API-Anforderung)
  • Kontextname (Beispiel): order_status_response
  • Headers:
    • X-Api-Key: <Dein-API-Key deines Shopsystems>
    • Content-Type: application/json
  • Body (Beispiel) in JSON-Code:
{
  "orderNumber": "{{order_number_input}}",
  "email": "{{email_input}}"
}

3. Optional: Authentifizierung via Login (Alternative zur E-Mail-Abfrage)

Der Abfrage-Prozess kann durch eine automatische Identitätserkennung optimiert werden. Ist eine Person bereits im Kundenkonto eingeloggt, entfällt die manuelle Abfrage der E-Mail-Adresse. In diesem Fall ist lediglich die Eingabe der Bestellnummer erforderlich, um den Versandstatus abzurufen.

Formular-Gestaltung mit dem Conditional Switch

Die Steuerung, ob ein Login vorhanden ist oder nicht, erfolgt im Formular über das Element Conditional Switch.

  1. Im Formular-Editor wird das Element Conditional Switch ausgewählt.
  2. Über das 3-Punkte-Menü hinter einer Bedingung wird die Bearbeitungsmaske geöffnet.
  3. In der Maske Bedingung bearbeiten werden der Variablenname, der Bedingungsoperator und der Vergleichswert definiert.
  4. Mit Klick auf BEARBEITEN wird die Bedingung gespeichert.
  5. Über das Plus-Symbol lassen sich weitere Verzweigungen hinzufügen, um verschiedene Login-Zustände abzubilden.

Folgende drei Bedingungen werden für eine präzise Steuerung empfohlen:

  • jwt = logout: Dieser Status signalisiert, dass die Person zuvor eingeloggt war, die Sitzung jedoch beendet wurde. Hier erfolgt die Ausgabe eines Hinweistextes mit Verlinkung zum erneuten Login.
  • jwt existiert: Die Person ist erfolgreich eingeloggt. Das Formular leitet unmittelbar zur Abfrage der Bestellnummer weiter.
  • uniqueUserId existiert: Diese Bedingung dient als Fallback, falls keine Authentifizierung vorliegt. Die Person wird aufgefordert, sich einzuloggen.

Die Variablennamen wie jwt müssen exakt so geschrieben werden, wie sie vom externen System (z. B. Shopify) übergeben werden. Eine abweichende Schreibweise führt dazu, dass die Bedingung nicht greift.

Die Variable uniqueUserId wird automatisch von moinAI bereitgestellt und enthält eine anonyme Identifikationsnummer für jede:n Nutzer:in. Da jede Person im Chat zwingend über eine solche ID verfügt, ist diese Bedingung immer erfüllt. Sie eignet sich daher ideal als Fallback-Pfad innerhalb eines Conditional Switch.

JWT (JSON Web Token)

Ein JWT kann man sich wie ein digitales Festival-Bändchen vorstellen. Einmal erhalten, dient es für den Rest des Prozesses als Beweis, dass die Person bereits erfolgreich kontrolliert wurde.

Webhook-Konfiguration bei Login-Authentifizierung

Damit das Shopsystem erkennt, dass die Anfrage von einer bereits verifizierten Person stammt, muss das Sicherheitsticket (JWT) im Webhook mitgesendet werden.

Dies erfolgt in der Webhook-Gestaltung unter Headers anpassen (optional):

  • Field: Authorization
  • Value: Bearer

Zweck dieser Konfiguration: Durch diesen Header weist sich der KI-Chatbot gegenüber der API als autorisierter Vertreter der eingeloggten Person aus. Das System erkennt das Token und gibt die Bestelldaten frei, ohne dass eine zusätzliche E-Mail-Validierung im Chat-Verlauf notwendig ist.

4. Logik der Antwortnachricht (Handlebars)

Um auf verschiedene Rückgabewerte des Systems (z. B. „storniert", „in Bearbeitung", „versendet") zu reagieren, werden im Textblock des Formulars Handlebars-Vorlagen mit if-Verzweigungen eingesetzt. Dadurch werden technische Statusbezeichnungen in kundenfreundliche Texte übersetzt.

Beispiel eines Code-Schnipsels für die Status-Antwort:

{{#if shopify_order_status_url}}

{{#if shopify_shopify_fulfillments}}

{{#if (eq shopify_status "pending")}}

Deine Bestellung ist bearbeitet, aber wurde noch nicht versandt.{{/if}}
{{#if (eq shopify_status "open")}}

Deine Bestellung wurde versandt.{{/if}}

{{#if (eq shopify_status "success")}}

Deine Bestellung wurde bestätigt.{{/if}}

{{#if (eq shopify_status "cancelled")}}

Deine Bestellung wurde storniert.{{/if}}

{{#if (eq shopify_status "error")}}

Es gab einen Fehler bei der Lieferung.{{/if}}

{{#if (eq shopify_status "failure")}}

Es ist etwas schief gelaufen bei der Lieferung.{{/if}}

{{else}}

Deine Bestellung wurde noch nicht versandt{{/if}}

{{else}}

Es gibt derzeit keine Bestellung für deine Angaben. Prüfe nochmals die Angaben oder schau auf der Bestellstatus-Seite nach:{{/if}}

Jedes Shopsystem gibt Daten in unterschiedlichen Formaten aus. Die hier gezeigten Code-Beispiele müssen daher an die spezifischen Variablenbezeichnungen des eigenen Systems angepasst werden.

5. Dynamische Buttons und Fallbacks

Zusätzlich zum Textblock können Buttons genutzt werden, die ihr Verhalten basierend auf dem Webhook-Ergebnis ändern. Dies ist besonders nützlich, um direkt zur Sendungsverfolgung des Versanddienstleisters (z. B. DHL) zu verlinken.

  • Bedingter Button-Text: Der Button zeigt „Versandstatus anzeigen" nur dann, wenn ein Paket verschickt wurde. Andernfalls erscheint ein allgemeiner Text wie „Bestellstatus".
{{#if order_status_response.tracking_url}}Sendung verfolgen{{else}}Zum Kundenkonto{{/if}}
  • Bedingte Button-URL: Die Verlinkung führt entweder direkt zur Tracking-URL oder als Fallback auf eine allgemeine FAQ-Seite oder das Kundenkonto.
{{#if order_status_response.tracking_url}}{{order_status_response.tracking_url}}{{else}}https://ihrshop.de/login{{/if}}

Diese Logik stellt sicher, dass Nutzer:innen stets ein hilfreiches nächstes Ziel angeboten bekommen (Fallback auf das Kundenkonto oder FAQ), falls noch keine Sendungsnummer vorliegt.

Die Umsetzung solcher Bedingungen in Buttons erfolgt über die Handlebars-Syntax innerhalb der Felder Button-Text und Button-URL.

Jedes Shopsystem gibt Daten in unterschiedlichen Formaten aus. Die hier gezeigten Code-Beispiele müssen daher an die spezifischen Variablenbezeichnungen des eigenen Systems angepasst werden.

6. Best Practice: Authentifizierung und Sicherheit

Als zusätzliche Sicherheitsprüfung kann die Bestellstatus-Abfrage an den Anmeldestatus der Nutzer:innen gekoppelt werden. Durch die Nutzung von Kontext-Informationen lässt sich prüfen, ob eine Person bereits eingeloggt ist.

  • Präzise Validierung: Die Nutzung von RegExp für die Bestellnummer (z. B. Prüfung auf 11 Stellen und Startziffer "9") minimiert fehlerhafte API-Aufrufe und verbessert die Erfahrung der Nutzer:innen.

  • Sicherheitsabfrage: Die Kombination aus Bestellnummer und E-Mail-Adresse dient als Legitimation.