Zalando mit JTL-Wawi verbinden

Viele JTL-Händler suchen unter dem Stichwort Zalando JTL eine klare Antwort: Lässt sich Zalando an die JTL-Wawi anbinden – und wenn ja, wie? Eine native Zalando-Verkaufskanal-Funktion in der JTL-Wawi gibt es dafür nicht. Die Anbindung erfolgt als Integrationsprojekt über Middleware.

Dieser Beitrag erklärt den belegten Weg über t4data.cloud Marketplaces: welche Systeme beteiligt sind, wie Artikel, Bestände, Bestellungen und Versandstatus fließen und welche Voraussetzungen auf Zalando-, JTL- und T4DT-Seite nötig sind.

Aktuelles JTL-Logo
Aktuelles Zalando-Logo (Wordmark)

Inhalt

• Kann Zalando mit JTL-Wawi verbunden werden?
• Welche Rolle übernimmt t4data.cloud Marketplaces?
• So funktioniert der Datenaustausch
• Artikel, Preise und Bestände übertragen
• Bestellungen und Versandstatus verarbeiten
• Voraussetzungen für die Zalando-Anbindung
• Praxisbeispiel: Zalando und JTL in der Praxis
• Grenzen und projektspezifische Anforderungen
• Für wen eignet sich die Lösung?
• FAQ

Kann Zalando mit JTL-Wawi verbunden werden?

Ja – aber nicht wie ein gewöhnlicher JTL-Verkaufskanal per Mausklick. Zalando stellt Händlern eigene Partner- und Schnittstellenprozesse bereit (unter anderem über das Partner-Programm und die Anbindung über Zdirect). Die JTL-Wawi kennt diesen Marktplatz nicht als Standardmodul.

Zwischen Warenwirtschaft und Zalando braucht es deshalb eine Vermittlungsschicht: Daten müssen gemappt, validiert und in marktplatzfähige Formate gebracht werden. Bei T4DT erfolgt das für den empfohlenen Weg über t4data.cloud Marketplaces mit der Middleware von Rithum (vormals ChannelAdvisor) und dem lokalen CaCommunicator als Brücke zur JTL-Wawi.

Technisch möglich ist Zalando zudem über Tradebyte/TB.One mit dem TbCommunicator. Intern gilt die Leitlinie: Wo möglich, wird Rithum über t4data.cloud Marketplaces bevorzugt; Tradebyte vor allem, wenn ein Marktplatz über Rithum nicht abbildbar ist. Für Zalando sind beide Wege technisch belegt – der Fokus dieses Beitrags liegt auf Marketplaces/Rithum.

Welche Rolle übernimmt t4data.cloud Marketplaces?

t4data.cloud Marketplaces ist die zentrale Marktplatzlösung von T4DT. Sie verbindet die bestehende Warenwirtschaft – in der Praxis häufig die JTL-Wawi – mit nationalen und internationalen Marktplätzen. Zalando gehört zu den Marktplätzen, die dort über Rithum angebunden und mitgesteuert werden können.

Konkret übernimmt die Lösung drei Aufgaben: Sie nimmt die benötigten Daten aus der JTL-Wawi entgegen (über den CaCommunicator als lokalen Hintergrunddienst), transformiert und mappt sie in der Middleware (Templates, Business Rules, Lookup-Listen) und überträgt sie an Zalando. Im Rückkanal laufen Bestellungen und Statusinformationen wieder in die Wawi.

T4DT agiert dabei als Rithum Agency und einziger Ansprechpartner für das Middleware-Setup. Den Händlervertrag mit Zalando schließen Sie weiterhin selbst – auf Wunsch mit Begleitung durch T4DT. Eine offizielle Zalando-Zertifizierung oder Partnerschaft wird hier nicht behauptet; beschrieben wird die technische Vermittlungsleistung.

Schema: JTL-Wawi, t4data.cloud Marketplaces und Zalando-Partneranschluss als Datenfluss

So funktioniert der Datenaustausch

Der belegte Ablauf für t4data.cloud Marketplaces mit JTL und Zalando sieht so aus:

1. Daten entstehen in der JTL-Wawi

Artikelstammdaten, Bilder, Preise und Bestände werden in der Warenwirtschaft gepflegt – dort, wo Händler sie ohnehin führen (Kundengruppenpreise, Merkmale, eigene Felder, Attribute). Die JTL-Wawi bleibt führendes System für Lager und Auftragsabwicklung.

2. CaCommunicator stellt die Daten bereit

Der CaCommunicator läuft als Hintergrunddienst auf dem Händlersystem und tauscht sich lokal mit dem JTL-Worker aus. Er übernimmt die Synchronisation zwischen JTL-Wawi und der Rithum-/ChannelAdvisor-Middleware. Abgleichsintervalle sind konfigurierbar.

3. t4data.cloud Marketplaces verarbeitet und mappt

In der Middleware werden Daten für Zalando aufbereitet: Template-Mapping, Business Rules und Lookup-Listen bringen Kategorien, Attribute und Angebotsfelder in die von Zalando geforderte Struktur. Für Produktcontent gilt bei Zalando zunehmend der Unified Mode mit einem Master-Profil als einziger Content-Quelle; Preise und Bestände können über weitere Profile laufen.

4. Übertragung an Zalando

Über die Rithum-Zalando-Anbindung (verbunden über Zdirect in den Einstellungen) gelangen Produkt- und Angebotsdaten an Zalando. Die Anbindung spricht damit die von Zalando bereitgestellte Partner-/Produkt-API-Welt an – nicht eine JTL-native Schnittstelle.

5. Rückkanal: Bestellungen und Status

Bestellungen und Statusinformationen laufen über dieselbe Middleware zurück in die JTL-Wawi. Versandmeldungen inklusive Tracking sowie Retourenmeldungen und Stornierungen werden in die Gegenrichtung zurückgespielt. Die Auftragsverarbeitung bleibt von Content-Umstellungen (Unified Mode) unberührt.

Hin- und Rückkanal: Produktdaten, Preise und Bestände sowie Bestellungen und Versandstatus

Artikel, Preise und Bestände übertragen

Von der JTL-Wawi über den CaCommunicator an die Middleware – und damit an Zalando – werden unter anderem Artikeldaten, Bilder, Preise und Bestände synchronisiert. Die Pflege bleibt in der Wawi; die Middleware mappt Felder auf Zalando-Templates und Pflichtattribute.

In der Praxis sind Kategorisierung, Materialzusammensetzung, Größenregister und saisonale Merkmale typische Mapping-Themen. Fehlerhafte oder unvollständige Attribute führen zu Ablehnungen oder Blockierungen auf Zalando-Seite. Das Onboarding neuer Artikel erfordert deshalb oft projektspezifische Regeln und Tests.

Bestände und Preise werden in definierbaren Intervallen aktualisiert. Im Unified Mode steuert das Master-Profil den Content; Non-Master-Profile dienen reduziert für Preis, Menge und Offer-Blocker. Ob ein Artikel in einem Land angeboten wird, lässt sich pro Locale steuern.

Bestellungen und Versandstatus verarbeiten

Vom Marktplatz über die Middleware in die JTL-Wawi gelangen Auftragsdaten. Sofern vom Marktplatz unterstützt, können auch Reservierungen für noch nicht bestätigte Verkäufe sowie der Bezahlstatus übertragen werden. Marktplatz-Stornierungen stornieren den Auftrag in der Wawi.

Nach der Kommissionierung und dem Versand in der JTL-Wawi gehen Versandmeldungen inklusive Trackingcode zurück an die Middleware und damit an Zalando. Retourentrackingcodes und Retourenmeldungen sind im CaCommunicator-Funktionsumfang enthalten und werden entsprechend zurückgemeldet.

Stornierungen wegen Lagermangel oder Kundenwunsch können von der JTL-Seite an die Middleware gemeldet werden. Welche Retouren- und Storno-Fälle im Einzelfall vollautomatisch greifen, hängt von Marktplatzregeln, Mapping und Projektrahmen ab – das ist Teil der kundenspezifischen Einrichtung, nicht einer pauschalen Garantie.

Voraussetzungen für die Zalando-Anbindung

Auf Zalando-Seite: aktiver Händlervertrag bzw. Freischaltung im Partner-Programm, Zugang zu Zdirect und die von Zalando geforderten Onboarding-Schritte (unter anderem KYC, Kategorien-Freigaben, Go-Live-Abstimmung). Weitere Länderkanäle können separate Freischaltungen und Wartezeiten bedeuten.

Auf JTL-Seite: produktive JTL-Wawi, in der Artikel, Preise und Bestände sauber gepflegt sind. Der CaCommunicator wird lokal installiert und an die Middleware angebunden. Ohne belastbare Stammdaten scheitert das Mapping – unabhängig von der Middleware.

Auf T4DT-Seite: aktive t4data.cloud-Marketplaces-Subskription (CaCommunicator ist im Cloud-Vertrag enthalten) sowie Einrichtung von Middleware, Zalando-Kanal, Templates und Regeln. Die Marktplatzanbindung selbst wird nach Aufwand berechnet; hinzu kommen einmalige Einrichtungskosten je Instanz laut aktueller Produktseite.

Optional beschleunigt der Marktplatz Concierge die Integration in einer intensiven Betreuungsschiene – Voraussetzung dort ist unter anderem eine laufende Cloud-Subskription und eine abgeschlossene CaCommunicator-Integration.

Praxisbeispiel: Zalando und JTL in der Praxis

Öffentlich dokumentierte Fälle zeigen, wie Fashion-Händler Zalando über Middleware an die JTL-Wawi anbinden – nicht als JTL-Standardkanal, sondern als Integrationsprojekt.

Fall 1 – Leogra Trading: Der Textil-Händler wollte Sortiment neben dem eigenen Shop auch auf Marktplätzen wie Otto und Zalando verkaufen. Tradebyte/TB.One war gewählt, fehlte aber die Brücke zur JTL-Wawi. Daraus entstand der TbCommunicator; parallel ist der CaCommunicator im Einsatz. Details: Success Story Leogra Trading.

Ausgangslage und Lösung bei Leogra: JTL-Wawi und Tradebyte sollten Produktdaten, Bestände, Bestellungen und Versandmeldungen austauschen. Der TbCommunicator schließt diese Lücke als Hintergrunddienst. Zusätzlich deckt der CaCommunicator weitere Marktplatzwege ab – weil unterschiedliche Marktplätze unterschiedliche Anbindungen erfordern.

Fall 2 – DD GmbH (Velvet-Shop): Auch hier war JTL vorhanden; Otto und Zalando sollten über Tradebyte/TB.One laufen. T4DT lieferte den TbCommunicator für die Synchronisation von Aufträgen, Artikeln, Beständen, Retouren und Reservierungen. Parallel nutzt DD GmbH t4data.cloud Marketplaces (Rithum + CaCommunicator), unter anderem für Limango. Details: Success Story DD GmbH.

Was beide Fälle belegen: Zalando lässt sich mit JTL verbinden – über Middleware und Communicator, nicht als natives JTL-Modul. Der Tradebyte-Weg (TbCommunicator) ist in den Success Stories zentral für Zalando/Otto dokumentiert. Der heute für t4data.cloud Marketplaces empfohlene Rithum-Weg (CaCommunicator + Zdirect) ist dieselbe Architekturlogik: JTL bleibt führend, die Middleware mappt und vermittelt.

Einordnung: Konkrete Umsatz- oder Zeitersparnis-Prozentwerte nennen wir hier nicht über die öffentlichen Stories hinaus. Belegt ist die betriebsfähige End-to-End-Kette und die Erweiterung um weitere Marktplätze. Für neue Projekte prüfen wir, ob Zalando über Rithum/Marketplaces oder – falls nötig – über Tradebyte angebunden wird.

Grenzen und projektspezifische Anforderungen

Die Anbindung ist kein JTL-Standardkanal, sondern ein Integrationsprojekt. Standardisiert sind die Communicator-Synchronisationsrichtungen und der Middleware-Rahmen. Kundenspezifisch sind Template-Mapping, Business Rules, Sortimentssteuerung je Locale, Test- und Go-Live-Abläufe sowie die Klärung, wer Mapping und Content-Pflege übernimmt.

Manuelle Schritte bleiben: Zalando-Onboarding und Freischaltungen, inhaltliche Datenbereinigung, Freigabe von Kategorien, Tests neuer SKUs und die Abstimmung des Go-Live-Datums mit Zalando. Unified-Mode-Umstellungen erfordern die Wahl eines Master-Profils und ggf. Content-Migration.

Nicht belegt und daher hier ausgeschlossen: eine native JTL-Zalando-Schnittstelle ohne Middleware, pauschale SLA-Versprechen, offizielle Zalando-Partnerschaftszertifikate oder garantierte Onboarding-Dauern in Minuten für Zalando (im Gegensatz zu anderen Marktplätzen, bei denen unter guten Voraussetzungen deutlich kürzere Listings möglich sein können).

Für wen eignet sich die Lösung?

Geeignet sind Händler, die bereits mit JTL-Wawi arbeiten oder arbeiten wollen, Zalando ernsthaft als Kanal betreiben und bereit sind, Datenqualität und Mapping mitzuziehen. Besonders sinnvoll wird die Lösung, wenn mehrere Marktplätze über dieselbe Middleware-Infrastruktur geplant sind – dann amortisiert sich das Marketplaces-Setup über den Kanal-Mix.

Weniger sinnvoll ist die Anbindung, wenn nur ein sehr kleines Zalando-Sortiment ohne wiederkehrende Volumen geplant ist, Stammdaten chaotisch sind oder niemand Kapazität für Mapping und Go-Live hat. Dann übersteigen Einrichtungsaufwand und laufende Middleware-Kosten den Nutzen – unabhängig vom technischen Potenzial.

Ob sich Zalando wirtschaftlich lohnt, hängt von Sortiment, Margen, Retourenquote und Zalando-Freigaben ab. T4DT liefert die technische Brücke und begleitet das Setup; die Marktplatzentscheidung und der Vertrag bleiben beim Händler.

FAQ

Gibt es eine native Zalando-Schnittstelle in der JTL-Wawi?

Nein. Zalando ist kein Standard-Verkaufskanal der JTL-Wawi. Die Anbindung läuft über Middleware – bei t4data.cloud Marketplaces über Rithum und den CaCommunicator.

Welche Systeme sind an der Zalando-JTL-Anbindung beteiligt?

JTL-Wawi (Stammdaten, Lager, Aufträge), CaCommunicator (lokale Brücke), t4data.cloud Marketplaces / Rithum (Mapping und Marktplatzkanal) sowie Zalando über Partner-/Zdirect-Anbindung.

Werden Bestände, Preise und Bestellungen synchronisiert?

Ja, im belegten Funktionsumfang: Artikeldaten, Bilder, Preise und Bestände Richtung Marktplatz; Aufträge, Bezahlstatus und ggf. Reservierungen zurück in die Wawi; Versand- und Retourenmeldungen inklusive Tracking zurück an den Marktplatz.

Ist die Anbindung ein fertiges Plug-and-Play-Produkt?

Nein. Es handelt sich um ein Integrationsprojekt. Communicator und Middleware-Rahmen sind standardisiert; Mapping, Regeln, Sortiment und Go-Live sind kundenspezifisch.

Welche Voraussetzungen muss ich bei Zalando erfüllen?

Einen gültigen Händlervertrag bzw. Freischaltung im Partner-Programm, Zugang zu Zdirect sowie die von Zalando geforderten Onboarding-Schritte (KYC, Kategorien, Go-Live-Abstimmung).

Wann lohnt sich die Anbindung wirtschaftlich eher nicht?

Bei sehr kleinem Sortiment ohne nachhaltiges Volumen, fehlender Datenqualität oder ohne Kapazität für Mapping und Go-Live. Dann übersteigen Einrichtungs- und Middleware-Kosten den Nutzen.

Zalando an JTL anbinden – nächster Schritt

Wenn Sie Zalando mit JTL-Wawi verbinden wollen und den konkreten Weg über t4data.cloud Marketplaces prüfen möchten, sprechen Sie uns an. Wir klären Voraussetzungen, Mapping-Aufwand und ob Rithum für Ihr Setup der passende Weg ist.

Zu t4data.cloud Marketplaces Kontakt aufnehmen