Menü
Zertifizierter Lexware Technologie-Partner

KI-Artikeltexte per Knopfdruck: Was JTL-Wawi-Workflows heute schon können

Artikelbeschreibungen sind die Baustelle, die nie fertig wird. Die Ware ist da, die Bilder sind da, nur der Text fehlt. Also öffnet man ChatGPT im Browser, kopiert Artikelnamen hin, Text her, zehnmal, fünfzigmal. Dabei kann die Wawi das selbst. Mit Bordmitteln, ohne Plugin, per Rechtsklick.

Von Henning Schröder ~9 Min. Lesezeit
TL;DR

JTL-Wawi bringt alles mit, um KI-Texte per Knopfdruck zu erzeugen: manuelle Workflow-Ereignisse als Auslöser3, die Web-Request-Aktion für den API-Aufruf an OpenAI & Co.1, DotLiquid für den Prompt mit echten Artikeldaten und globale Textbausteine als zentralen Speicher für API-Key und Prompts. Die Antwort landet über „Werte setzen" direkt im Artikel, am besten erst in einem eigenen Feld zur Kontrolle. Die eine ehrliche Schwachstelle: JTL-Wawi kann die JSON-Antwort der API nicht nativ parsen7. Entweder du filterst per DotLiquid, oder du schaltest einen schlanken Relay-Endpunkt dazwischen, der nur reinen Text zurückgibt. Kostenpunkt pro Artikeltext: Cent-Bruchteile. Zeitersparnis: real. Qualitätskontrolle: bleibt bei dir.

KI-generierte Artikeltexte per Workflow in JTL-Wawi

Das Problem: Copy & Paste als Geschäftsprozess

Fast jeder Händler, mit dem ich spreche, nutzt inzwischen KI für Produkttexte. Und fast jeder nutzt sie gleich: Browser auf, ChatGPT-Tab, Artikeldaten aus der Wawi kopieren, Prompt tippen, Ergebnis zurückkopieren, Formatierung reparieren, speichern. Pro Artikel drei bis fünf Minuten, von denen die KI selbst vielleicht zehn Sekunden braucht. Der Rest ist Fensterwechsel.

Das ist kein KI-Workflow. Das ist ein Kopier-Workflow mit KI-Beteiligung. Die eigentliche Frage lautet: Warum verlässt der Artikel überhaupt die Wawi? Die Daten liegen dort, das Zielfeld liegt dort, und die Wawi kann seit Version 1.3 HTTP-Anfragen aus Workflows heraus senden und die Antwort in Felder schreiben1. Alles, was zwischen Artikel und fertigem Text steht, ist ein bisschen Konfiguration.

Was möglich ist: mehr als Artikelbeschreibungen

Der Mechanismus, um den es gleich geht, ist erstaunlich generisch. Er nimmt Artikeldaten, schickt sie mit einem Prompt an eine KI-API und schreibt die Antwort in ein Feld deiner Wahl. Was in diesem Feld landet, bestimmt allein der Prompt. In der Praxis heißt das:

Artikelbeschreibungen und Kurzbeschreibungen, generiert aus Artikelname, Hersteller und Merkmalen. SEO-Metadaten, also Title und Meta-Description mit Zeichenlimit, das du im Prompt festnagelst. FAQs zum Produkt, die als eigenes Feld im Shop ausgegeben werden. Marktplatz-Varianten desselben Textes, einmal sachlich für den Shop, einmal keyword-lastig für eBay. Und Übersetzungen in die Sprachfelder der Wawi, wahlweise per KI oder nach exakt demselben Muster über die DeepL-API2. Dienstleister im JTL-Umfeld bauen auf genau dieser Basis komplette Text-Pipelines für Titel, Stichpunkte, Beschreibungen und Eigene Felder9.

Ein Feld, ein Prompt, ein Workflow. Wer das dreimal eingerichtet hat, denkt bei jedem Freitextfeld in der Wawi anders darüber nach, wer es eigentlich befüllen sollte.

Die vier Bausteine in der Wawi

Bevor wir klicken, kurz die Teile sortieren. Es sind vier, und alle sind Bordmittel.

1. Manuelle Workflow-Ereignisse. Workflows in JTL-Wawi folgen immer dem Muster Ereignis, Bedingung, Aktion4. Neben automatischen Auslösern wie „Artikel erstellt" gibt es die Ereignisgruppen mit dem Zusatz Manuell, etwa „Artikel – Manuell". Ein dort angelegtes Ereignis taucht in der Artikelverwaltung im Kontextmenü unter „Workflow-Ereignis auslösen" auf3. Das ist der Knopfdruck aus der Überschrift: Artikel markieren, Rechtsklick, Ereignis wählen. Funktioniert auch für zwanzig markierte Artikel auf einmal. Beachte nur: Die Anzahl manueller Workflow-Ereignisse ist je nach JTL-Edition begrenzt, also geh sparsam damit um3.

2. Die Web-Request-Aktion. Innerhalb eines Workflows gibt es die Aktion „Web-Request". Wichtig: die Variante ohne den Zusatz „(POST)" nehmen, dort die Methode im Dropdown auf POST stellen. Diese Variante kann Header setzen, einen Body mitgeben und, entscheidend, die Antwort des Servers über „Werte setzen" in Felder des auslösenden Objekts schreiben1. Genau dieser Rückkanal existiert seit Wawi 1.3 und macht den ganzen Ansatz erst möglich.

3. DotLiquid. Die Template-Sprache der Wawi5. Überall, wo im Web-Request Platzhalter stehen, löst DotLiquid sie zur Laufzeit gegen echte Artikeldaten auf. Der Prompt „Schreibe eine Beschreibung für {{ Artikelname }}" wird also pro Artikel individuell. Die exakten Platzhalter-Pfade ziehst du dir am besten aus dem DotLiquid-Editor der Wawi, die Punktnotation unterscheidet sich je nach Kontext und Version.

4. Globale Textbausteine. Zu finden in der Wawi-Verwaltung als „Globale Texte", gedacht für wiederverwendbare Textblöcke und Code, einsetzbar überall dort, wo DotLiquid läuft6. Und hier kommt der Kniff, der die Wartung rettet: API-Key und System-Prompt gehören nicht in jeden Workflow einzeln, sondern jeweils in einen globalen Textbaustein. Ändert sich der Key oder willst du am Prompt feilen, änderst du eine Stelle, und alle Workflows ziehen mit. Wer fünf KI-Workflows mit fünf hart codierten Keys gepflegt hat, weiß, warum dieser Absatz existiert.

Schritt für Schritt: der KI-Workflow

Schritt 1: API-Zugang und Textbausteine anlegen

Du brauchst einen API-Key eines KI-Anbieters, im Beispiel OpenAI8. Wichtig: Das ist ein separater Zugang mit nutzungsbasierter Abrechnung, kein ChatGPT-Plus-Abo. Leg beim Anbieter direkt ein monatliches Ausgabenlimit fest, zehn Euro reichen für tausende Artikeltexte.

In der Wawi legst du zwei globale Textbausteine an: einen namens KI_API_Key mit dem Key als Inhalt, einen namens KI_SystemPrompt_Artikeltext mit deiner Stil-Anweisung. Der System-Prompt ist der Ort für alles, was für jeden Artikel gleich ist: Tonalität, Zielgruppe, Länge, verbotene Floskeln, HTML ja oder nein. Je konkreter, desto weniger Nacharbeit.

Schritt 2: Manuelles Workflow-Ereignis anlegen

Unter Admin > JTL-Workflows im Bereich Artikel den Knoten Artikel – Manuell wählen und ein neues Ereignis anlegen, etwa „KI: Artikeltext erzeugen"3. Als Bedingung bietet sich eine Sicherung an, zum Beispiel: nur ausführen, wenn die Beschreibung leer ist. So überschreibt ein versehentlicher Klick keine handgepflegten Texte.

Schritt 3: Web-Request konfigurieren

Als Aktion „Web-Request" wählen, Methode POST, URL https://api.openai.com/v1/chat/completions8. In den Header kommen zwei Zeilen, getrennt durch Zeilenumbruch:

Authorization: Bearer {{ GlobalerText: KI_API_Key }}
Content-Type: application/json

Die Schreibweise, mit der globale Textbausteine in Workflows referenziert werden, bietet dir der DotLiquid-Editor deiner Wawi-Version in der Platzhalter-Auswahl an; die Zeile oben ist exemplarisch. Der Body ist das JSON, das die OpenAI-API erwartet, gefüllt mit DotLiquid-Platzhaltern (auch hier: Pfade exemplarisch, bitte aus dem Editor der eigenen Version übernehmen):

{
  "model": "gpt-4o-mini",
  "messages": [
    { "role": "system", "content": "[System-Prompt aus globalem Textbaustein]" },
    { "role": "user", "content": "Schreibe eine Artikelbeschreibung für:
      Artikelname: [Platzhalter Artikelname]
      Hersteller: [Platzhalter Hersteller]
      Merkmale: [Platzhalter Merkmale]" }
  ]
}

Eine Falle, die garantiert zuschnappt: Anführungszeichen in Artikelnamen. Ein Zollzeichen im Namen, etwa 24"-Monitor, zerlegt dein JSON, und die API antwortet mit einem 400er. Deshalb jeden eingesetzten Platzhalter per DotLiquid-Filter entschärfen, mindestens Replace für Anführungszeichen und Zeilenumbrüche. Unspektakulär, aber der Unterschied zwischen „läuft" und „läuft bei 97 Prozent der Artikel".

Schritt 4: Antwort ins Feld schreiben

Unterhalb des Web-Requests bietet die Aktion „Werte setzen" an, die Server-Antwort in ein Feld zu schreiben1. Mein Rat: nicht direkt in die Artikelbeschreibung, sondern erst in ein eigenes Feld, etwa KI_Textentwurf. Ein zweiter, ebenfalls manueller Workflow „KI: Entwurf übernehmen" kopiert den geprüften Text dann in die Beschreibung. Das baut eine Review-Schleife in den Prozess, ohne dass jemand die Wawi verlassen muss. Generieren per Knopfdruck, prüfen mit den eigenen Augen, übernehmen per Knopfdruck.

Die ehrliche Stelle: das JSON-Problem

Jetzt der Teil, den die meisten Anleitungen verschweigen. Die Web-Request-Aktion schreibt die rohe Antwort ins Feld. Die OpenAI-API antwortet aber nicht mit deinem Text, sondern mit einem JSON-Objekt, in dem dein Text irgendwo unter choices[0].message.content steckt, umgeben von Modellnamen, Token-Zählern und Metadaten. Und JTL-Wawi hat, Stand heute, keinen eingebauten JSON-Parser für Workflow-Antworten. Das Forum ist voll mit Threads dazu, seit Jahren7.

Es gibt zwei gangbare Wege.

Weg A: DotLiquid-Chirurgie. Die Antwort landet in einem Zwischenfeld, ein Folge-Workflow zerlegt sie mit Filtern wie Split, Replace und Truncate, bis nur der Text übrig ist. Das funktioniert, die Community hat es für DeepL und andere APIs vorgemacht10. Es ist aber fragil: Ändert der Anbieter die Antwortstruktur oder enthält der generierte Text selbst einen Doppelpunkt an ungünstiger Stelle, bricht die Zerlegung. Für den Einstieg und kleine Kataloge in Ordnung, auf Dauer eher Bastelei.

Weg B: ein schlanker Relay-Endpunkt. Ein kleines Skript auf dem eigenen Webspace, dreißig Zeilen PHP genügen, nimmt den Request der Wawi an, ruft die KI-API auf und gibt ausschließlich den reinen Text zurück, Content-Type text/plain. Die Wawi schreibt die Antwort dann eins zu eins ins Feld, kein Parsing, kein Bruch. Als jemand, der beruflich API-Brücken baut, bin ich hier naturgemäß voreingenommen. Aber der Relay hat noch zwei Nebeneffekte: Der API-Key kann komplett aus der Wawi verschwinden und im Skript liegen, und du kannst den Anbieter wechseln, ohne einen einzigen Workflow anzufassen.

Welcher Weg der richtige ist, hängt davon ab, wer ihn pflegt. Wer keinen Webspace und keine Lust auf PHP hat, fährt mit Weg A oder mit einer fertigen Erweiterung aus dem JTL Extension Store besser9. Wer ohnehin einen Server betreibt, ist mit Weg B in einer Stunde durch und hat danach Ruhe.

Vom Artikeltext zur FAQ

Sobald der erste Workflow läuft, ist der zweite eine Kopie mit anderem Prompt und anderem Zielfeld. Für Produkt-FAQs heißt das: eigenes Feld oder Attribut Produkt_FAQ anlegen, im Prompt drei bis fünf Frage-Antwort-Paare zu Material, Pflege, Kompatibilität und Lieferumfang anfordern, als sauberes HTML mit einer festen Struktur, die dein Shop-Template kennt. Das Template gibt das Feld auf der Artikelseite aus, fertig.

Der unterschätzte Effekt daran: FAQs beantworten genau die Fragen, die sonst als E-Mail im Support landen. Zehn Artikel mit generierten und, wichtig, gegengelesenen FAQs sparen keine Stunden bei der Texterstellung, sondern Stunden im Kundenservice. Dasselbe Muster trägt Meta-Descriptions, eBay-Texte und Übersetzungen. Der Mechanismus bleibt identisch, nur Prompt und Zielfeld wandern.

Was es bringt und wo die Grenzen liegen

Rechnen wir kurz. Erfahrungswerte aus dem JTL-Forum: rund 600 bis 800 Token pro Anfrage, bis zu 2.000 pro Antwort11. Bei aktuellen Preisen kostet eine Artikelbeschreibung damit Bruchteile eines Cents. Die drei bis fünf Minuten Fensterwechsel pro Artikel dagegen kosten bei 200 Artikeln einen vollen Arbeitstag. Die Rechnung muss man niemandem vorrechnen, sie rechnet sich selbst.

Dazu kommt Konsistenz: Ein zentraler System-Prompt erzeugt einen einheitlichen Ton über den ganzen Katalog, egal ob den Knopf der Chef oder die Aushilfe drückt. Und die Texte entstehen dort, wo sie gebraucht werden, ohne Toolwechsel, ohne Zwischenablage, ohne Formatierungsreparatur.

Aber, und dieses Aber gehört in jeden ehrlichen Text zu dem Thema: Die KI kennt dein Produkt nicht. Sie kennt deinen Prompt. Fehlen Merkmale im Artikel, erfindet sie plausibel klingende. Ein generierter Text, der ungeprüft in den Shop geht, ist ein Haftungsrisiko mit guter Grammatik, spätestens bei Materialangaben oder Kompatibilitätsaussagen. Deshalb die Review-Schleife über das Zwischenfeld, deshalb der Knopfdruck statt des vollautomatischen Triggers bei Artikelanlage. Der Mensch bleibt im Prozess, die Maschine übernimmt den Rohbau.

Zwei Punkte noch fürs Kleingedruckte. Erstens: Globale Textbausteine liegen im Klartext, der API-Key ist für Wawi-Benutzer einsehbar6. Ausgabenlimit setzen, separaten Key nur für die Wawi verwenden, im Zweifel den Relay-Weg gehen. Zweitens: Mit jedem Request wandern Artikeldaten an einen externen Anbieter, meist in die USA. Bei Produktdaten ist das datenschutzrechtlich entspannt, bei allem, was Kundendaten enthält, etwa dem verlockenden Gedanken, auch gleich Auftragsdaten durch die KI prüfen zu lassen, ist es ein Fall für einen prüfenden Blick, bevor man klickt.

Was du jetzt tun kannst

  • API-Zugang anlegen und Limit setzen. Separater Key nur für die Wawi, monatliches Ausgabenlimit beim Anbieter. Fünf Minuten, die dich vor Überraschungen schützen.
  • Zwei globale Textbausteine anlegen. Einen für den Key, einen für den System-Prompt. Ab jetzt gibt es genau eine Stelle, an der du Stil und Zugang pflegst.
  • Mit einem manuellen Ereignis und zehn Testartikeln starten. Bedingung „Beschreibung ist leer" als Sicherung, Antwort in ein Zwischenfeld, Ergebnis lesen. Erst wenn die Qualität stimmt, den Übernahme-Workflow bauen.
  • Das JSON-Problem bewusst entscheiden. DotLiquid-Filter für den schnellen Start, Relay-Endpunkt für den ruhigen Dauerbetrieb, fertige Extension, wenn beides nicht dein Terrain ist.
  • Jeden generierten Text gegenlesen, bevor er live geht. Die Review-Schleife ist kein optionaler Komfort, sie ist der Teil des Workflows, der dich vor erfundenen Produktfakten schützt.

Über den Autor

Henning Schröder ist Gründer und Entwickler von intercon-systems und seit über einem Jahrzehnt auf REST-API-Integrationen, Backend-Entwicklung und E-Commerce-Schnittstellen spezialisiert. intercon-systems ist zertifizierter Lexware Technologie-Partner und betreibt eine produktiv eingesetzte JTL-Wawi-Schnittstelle zu Lexware Office.

Henning auf LinkedIn ➜

Häufige Fragen

Brauche ich ein Plugin oder eine Erweiterung, um KI-Texte in JTL-Wawi zu erzeugen?

Nein. Manuelle Workflow-Ereignisse, die Web-Request-Aktion und globale Textbausteine sind Bordmittel von JTL-Wawi. Du brauchst zusätzlich nur einen API-Zugang bei einem KI-Anbieter, etwa OpenAI. Fertige Erweiterungen aus dem JTL Extension Store nehmen dir die Einrichtung ab, sind aber nicht Voraussetzung.

Was kostet die Textgenerierung pro Artikel?

Erfahrungswerte aus dem JTL-Forum liegen bei rund 600 bis 800 Token pro Anfrage und bis zu 2.000 Token pro Antwort. Bei aktuellen Modellen bewegt sich eine Artikelbeschreibung damit im Bereich von Bruchteilen eines Cents bis wenigen Cent. Der eigentliche Kostenfaktor ist nicht die API, sondern die Zeit für die Qualitätskontrolle.

Warum landet die KI-Antwort mit JSON-Müll in meinem Feld?

Die Web-Request-Aktion schreibt die rohe HTTP-Antwort in das Zielfeld, und die APIs der KI-Anbieter antworten in JSON. JTL-Wawi hat keinen eingebauten JSON-Parser für Workflow-Antworten. Entweder du extrahierst den Text per DotLiquid-Filtern wie Split und Replace, oder du schaltest einen schlanken Relay-Endpunkt dazwischen, der nur den reinen Text zurückgibt.

Ist der API-Key im globalen Textbaustein sicher?

Er ist zentral, aber nicht geheim: Globale Textbausteine liegen im Klartext und sind für Wawi-Benutzer mit entsprechenden Rechten einsehbar. Für ein kleines Team ist das meist in Ordnung. Wer das Risiko reduzieren will, setzt beim Anbieter ein Ausgabenlimit, nutzt einen eigenen Key nur für die Wawi und kann ihn jederzeit zurückziehen, oder verlagert den Key komplett in einen Relay-Endpunkt.

Kann ich so auch FAQs oder Übersetzungen erzeugen?

Ja. Der Mechanismus ist immer derselbe: Prompt, Web-Request, Zielfeld. Für FAQs schreibst du die Antwort in ein eigenes Feld oder Attribut, das dein Shop-Template ausgibt. Für Übersetzungen füllst du die Sprachfelder der Wawi; statt einer KI-API funktioniert dafür auch die DeepL-API nach demselben Muster.

Quellen und Fundstellen

Damit du das alles auch nachprüfen kannst, ohne mir glauben zu müssen:

JTL Primärquellen

Community und Praxis

API-Dokumentation

Die beschriebenen Menüpfade und Platzhalter beziehen sich auf aktuelle JTL-Wawi-Versionen und können je nach Version abweichen; die exakte DotLiquid-Syntax bietet dir der Platzhalter-Editor deiner Installation an. Generierte Produkttexte vor Veröffentlichung immer fachlich prüfen, insbesondere Material-, Sicherheits- und Kompatibilitätsangaben.

Zuletzt aktualisiert am: 13.07.2026

Beitrag teilen LinkedIn

Wenn die Texte automatisch entstehen, sollte es die Buchhaltung auch

Derselbe Gedanke, ein Stockwerk tiefer: Rechnungen aus JTL-Wawi wandern mit intercon-systems automatisch nach Lexware Office. 14 Tage kostenlos testen, keine Kreditkarte, kein Abo-Zwang.

Jetzt kostenlos starten → Fragen?
Conny

Conny

Online – antwortet sofort
Hallo! 👋 Ich bin Conny - die Assistentin für intercon-systems. Hast du Fragen zu unseren Schnittstellen?