Für Artikeldaten in der JTL-Wawi gibt es fünf Wege: die JTL-Ameise für einmalige Importe, CSV/Excel für flexible Listen, direkten SQL-Zugriff für große Datenmengen, die REST-API für wiederkehrende Automatisierung und KI für die Aufbereitung von Texten und Merkmalen. Welcher passt, hängt von Datenmenge, Frequenz und verfügbarem Know-how ab - nicht vom Ergebnis.
Die Frage klingt technisch, ist aber im Kern eine Geschäftsfrage: Wie oft kommen Daten herein, wie viele sind es, und wer darf dabei wie viel Verantwortung tragen? Die fünf Wege unterscheiden sich genau darin - und der falsche Weg kostet entweder unnötige Handarbeit oder ein Datenrisiko, das man erst merkt, wenn es wehtut.
Fünf Wege, fünf verschiedene Aufgaben
| Weg | Typische Aufgabe | Grenze |
|---|---|---|
| Ameise | einmalige, vorbereitete Importe | keine Automatisierung, Handarbeit bleibt |
| CSV / Excel | flexible Listen ohne Schnittstelle | Fehler bei Dubletten und Formaten |
| SQL | große Datenmengen, direkter Zugriff | Verantwortung für Schreibrechte und Backups |
| REST-API | wiederkehrende, automatisierte Übernahme | braucht Entwickler-Know-how |
| KI | Texte und Merkmale aufbereiten | transportiert keine Daten, schlägt nur vor |
Die ersten drei bringen Daten in die Wawi. Die API automatisiert das Bringen. Die KI bereitet Inhalte auf, bevor sie über einen der anderen Wege hineingehen. Diese Trennung ist der Schlüssel zur Entscheidung.
Die Ameise: der Bordweg für einmalige Importe
Die JTL-Ameise ist das Importwerkzeug der Wawi. Sie nimmt eine vorbereitete Datei entgegen und spielt sie ein. Für einen einmaligen Datenbestand - etwa eine erste Grundbefüllung oder eine einzelne Lieferantenliste - ist sie der unkomplizierteste Weg: keine Programmierung, keine Schnittstelle, es geht direkt.
Ihre Grenze liegt in der Wiederholung. Jede neue Liste heißt erneut vorbereiten, mappen, prüfen. Wer mehrere Lieferanten mit eigener Frequenz hat, verbringt die Zeit genau dort, wo sie sich am wenigsten lohnt. Genau dieser Punkt ist der Grund, warum sich viele Händler irgendwann eine Automatisierung wünschen - der Ablauf dahinter ist im Artikel Artikeldaten automatisch pflegen beschrieben.
CSV und Excel: flexibel, aber fehleranfällig
CSV-Dateien sind der kleinste gemeinsame Nenner zwischen Lieferant und Wawi. Fast jeder Lieferant kann sie liefern, und die Wawi kann sie lesen. Für ein überschaubares Sortiment oder seltene Importe reicht das.
Das Risiko steckt in den Details: Spaltenreihenfolgen, Einheiten, Trennzeichen, deutsche Umlaute, Dubletten. Ein fehlerhafter Import überschreibt Stammdaten oder legt Artikel doppelt an - und der Fehler fällt oft erst Wochen später auf, wenn Bestände nicht stimmen. CSV ist deshalb kein Weg für große oder häufige Datenmengen, sondern für den Einzelfall mit gründlicher Kontrolle.
SQL: schnell und mächtig, mit Verantwortung
Wer direkt auf die Wawi-Datenbank schreibt, kann große Datenmengen in Sekunden bewegen - ohne Dateien, ohne Zwischenschritte. Das ist der schnellste Weg, wenn wirklich viel hineinmuss.
Der Preis dafür ist Verantwortung. Ein SQL-Befehl kennt keine Rückfrage: Er überschreibt, löscht oder verändert, was die Anweisung sagt - auch wenn die Anweisung einen Fehler enthielt. Deshalb gehört vor jeden direkten Zugriff ein Backup, ein Testlauf auf einer Kopie und eine klare Regel, wer schreiben darf. Für die reine Auswertung ist Schreibzugriff ohnehin unnötig - dort genügt read-only, wie es auch unser MCP-Server für JTL-Wawi nutzt.
REST-API: für wiederkehrende Automatisierung
Die REST-API der JTL-Wawi ist der Weg für alles, was regelmäßig und automatisch laufen soll: ein Shop, ein Marktplatz-Tool oder ein Workflow, der Daten übernimmt, ohne dass jemand eine Datei in die Hand nimmt. Sie ist für Systeme und Entwickler gedacht - nicht für den gelegentlichen Einzelimport.
Zur Kostenlage kursieren widersprüchliche Zahlen. Die JTL-REST-API steht mit 300 Euro als offiziellem Listenpreis, wird aber in der aktuellen Beta-Phase nicht berechnet - ist also derzeit faktisch kostenlos nutzbar. Angaben Dritter mit anderen Monatspreisen beziehen sich meist auf deren eigenes Zusatzprodukt, nicht auf den JTL-Preis. Was die API von einem MCP-Server unterscheidet und wann welche Ebene passt, erklärt der Artikel MCP oder REST-API für die JTL-Wawi.
KI: keine Transportlösung, sondern Aufbereitung
KI übernimmt nicht das Einspielen, sondern das Vorbereiten: Sie liest strukturierte Merkmale und macht daraus konsistente Texte, Meta-Daten und FAQ-Vorschläge - im Stapel, zehn Artikel auf einmal statt einzeln. Entscheidend ist die Trennung: Die KI schlägt vor, ein Mensch gibt frei, und erst danach fließen die Daten über einen der anderen Wege in die Wawi.
Genau so ist es in der Fallstudie JTL-Artikelpflege automatisiert gelöst: Bei rund 6.000 Artikeln laufen Lieferantendaten automatisch ein, die KI erstellt Texte im Stapel, und zwei Mitarbeiter geben nur noch frei, bevor etwas in die Wawi zurückfließt.
Wie Sie sich entscheiden
Die Wahl folgt drei Fragen, in dieser Reihenfolge:
- Wie oft? Einmalig heißt Ameise oder CSV. Wiederkehrend heißt API - oder eine Automatisierung, die aus dem Import einen Prozess macht.
- Wie viel? Wenige hundert Artikel vertragen Handarbeit. Tausende Artikel, die regelmäßig kommen, nicht.
- Wer prüft? Je größer die Menge, desto wichtiger eine Freigabe-Stufe, bevor Daten produktiv werden - ob Mensch oder Regel.
Für die wiederkehrende Pflege ist die Kombination aus automatischem Import und menschlicher Freigabe meist die richtige - nicht mehr Handarbeit als nötig, aber keine Änderung ohne Kontrolle.
Checkliste vor dem ersten Import
Unabhängig vom Weg gilt vor jedem größeren Import dieselbe Liste:
- Backup. Ein vollständiger Stand, auf den Sie zurückkönnen.
- Testlauf. Zuerst auf einer Kopie oder mit einer kleinen Stichprobe.
- Validierung. Dubletten, Formate und Pflichtfelder prüfen, bevor die Daten produktiv sind.
- Freigabe. Eine benannte Person gibt frei - und erst dann läuft der Import in die produktive Wawi.
Diese vier Schritte kosten einmal Zeit und sparen sie danach dauerhaft - weil ein sauberer Import nie repariert werden muss.