Der native Export in Shopware 6 kann maximal 6.000 Produkte pro Durchlauf verarbeiten. Wer darüber hinausgeht, bekommt eine Fehlermeldung oder eine abgeschnittene CSV-Datei — und merkt es oft erst, wenn der Marketplace-Import die Hälfte des Sortiments als „unbekannt“ markiert. Das ist 2026 der häufigste Grund, warum Händler den Standard-Export verlassen und auf Scheduled Jobs oder die Admin API umsteigen.
Die eingebaute Export-Funktion der Plattform ist kein Marketing-Gimmick. Sie ist ein solides Werkzeug für Backups, Reporting und den Datenaustausch mit Marktplätzen, Warenwirtschaftssystemen und Analytics-Pipelines. Aber sie ist ein Werkzeug mit klar definierten Kanten. Wer diese Kanten kennt, spart sich Wochen an Debugging. Wer sie ignoriert, exportiert Produkte, die im Zielsystem niemand lesen kann.
Dieser Guide zeigt, was der native Export leistet, wo er kippt — und welche drei Alternativen Händler 2026 tatsächlich nutzen.
Was exportiert Shopware 6 im Standard — und was nicht?
Der native Export deckt die Kerndaten ab: Produkte, Kunden, Bestellungen, Kategorien, Eigenschaften und Bestandsdaten. Jeder dieser Datentypen lässt sich als CSV ausgeben, gefiltert nach Sprache, Sales Channel, Aktiv-Status oder Zeitraum. Für einen Shop mit 2.000 Artikeln, der monatlich eine Bestandsliste an den Großhändler schickt, ist das ausreichend.
Die Einschränkungen sitzen im Detail. Bestellpositionen werden nicht als verschachtelte Objekte exportiert, sondern als flache Zeilen — bei Multi-Item-Bestellungen entstehen Duplikate in der Auftragskopf-Spalte. Variantenprodukte erscheinen je nach Konfiguration entweder als Eltern-Artikel mit Varianten-IDs oder als separate Zeilen ohne gemeinsame Referenz. Beides ist konsistent, aber keines ist kompatibel mit dem, was Amazon, OTTO oder Kaufland im Seller-Backend erwarten.
Warum verlieren Händler bei großen Katalogen die Kontrolle über den Export?
Zwei Ursachen dominieren: Skalierung und Feld-Mapping.
Skalierung: Der Standard-Export lädt alle Datensätze in den PHP-Speicher, bevor er die CSV schreibt. Bei 10.000 Produkten mit jeweils 15 Eigenschafts-Zuordnungen und sechs Sprachvarianten liegt der Speicherbedarf schnell bei mehreren hundert Megabyte. Ohne angepasstes memory_limit bricht der Prozess ab — und zwar mitten in der Datei, nicht am Anfang. Das Ergebnis ist eine CSV, die valide aussieht, bis das Zielsystem an Zeile 4.211 scheitert.
Feld-Mapping: Eine Shopware-Produkt-CSV enthält Spalten wie manufacturerNumber, taxId und customFields als JSON-String. Amazon Business verlangt standard_product_id und list_price_with_tax. OTTO erwartet sku, ean und lieferzeit in separaten Spalten. Es gibt keine native Übersetzungsschicht. Jeder Marktplatz bedeutet ein eigenes Mapping-Sheet, eine eigene Validierungslogik und eine eigene Fehlerquelle.
Ein Katalog mit 20.000 SKUs, drei Marktplätzen und wöchentlichem Bestandsabgleich ist mit dem Standard-Export nicht wartbar. Nicht wegen fehlender Features, sondern wegen des manuellen Aufwands pro Zielsystem.
Wie funktioniert der Export über die Admin API — und wann lohnt er sich?
Die Admin API ist der saubere Weg für alles, was regelmäßig läuft. Statt die Oberfläche zu bedienen, fragt ein Skript die Endpunkte /api/search/product, /api/search/order oder /api/search/customer ab — mit Pagination, Filtern und Feldauswahl. Der entscheidende Vorteil: Der Export wird inkrementell. Statt den gesamten Katalog zu ziehen, fragt der Job nur Datensätze ab, deren updatedAt sich seit dem letzten Lauf geändert hat.
Für einen Händler mit täglichem Bestandsabgleich reduziert das die Datenmenge um 95 Prozent oder mehr. Die API liefert JSON, das sich in Python, Node oder einer Low-Code-Pipeline direkt auf Zielschemas mappen lässt. Der Aufwand liegt einmalig bei zwei bis vier Entwicklertagen für ein robustes Skript mit Retry-Logik und Fehlerprotokoll.
Grenzen: Die API verlangt einen API-User mit entsprechenden Rechten, ein Rate-Limit-Management und eine saubere Fehlerbehandlung, wenn ein Datensatz ungültige Referenzen enthält. Für Shopbetreiber ohne technische Ressourcen ist das keine Option.
- Native Export: richtig für Ad-hoc-Backups, kleine Kataloge (unter 5.000 SKUs), manuelle Reports.
- Admin API: richtig für Scheduled Jobs, inkrementelle Syncs, Multi-Marktplatz-Pipelines mit eigener Entwicklungsressource.
Welche Tools schließen die Lücke zwischen Shopware und Marktplatz 2026?
Zwischen native Export und Eigenentwicklung hat sich ein Markt für Middleware gebildet. Drei Kategorien sind relevant.
Marktplatz-Connector wie ChannelEngine, Tradebyte oder die Shopware-eigene App-Lösung übernehmen Mapping, Validierung und Rückkanal. Sie lesen Produkt- und Bestandsdaten aus Shopware und schreiben sie in die Schemas von Amazon, OTTO, Kaufland und Zalando. Der Vorteil: fertige Mappings, laufende Pflege bei Schema-Änderungen der Marktplätze. Der Nachteil: monatliche Kosten ab etwa 200 Euro aufwärts und eine Datenhoheit, die beim Dienstleister liegt.
PIM-Systeme wie Akeneo, Pimcore oder Plytix ziehen den Produktstamm aus Shopware ab und werden zur führenden Quelle. Der Shop wird zum Ausgabekanal. Das lohnt sich ab mehreren Verkaufskanälen, weil die Datenpflege zentralisiert wird — ist aber ein Projekt, kein Plug-and-Play-Schritt.
ETL-Tools wie n8n, Make oder Apache Airflow verbinden die Admin API mit beliebigen Zielen, ohne Code. Für Händler mit technischem Grundverständnis ist das der flexibelste Weg: API-Call, Transformations-Node, Ausgabe an S3, Google Sheets oder direkt an einen Marktplatz-Endpunkt.
Was sollte beim Export 2026 technisch beachtet werden?
Vier Punkte entscheiden über Erfolg oder Datenmüll.
Encoding und Trennzeichen: Shopware exportiert standardmäßig UTF-8 mit Semikolon als Trennzeichen. Amazon und OTTO erwarten in der Regel Komma-getrennte Werte. Excel öffnet Semikolon-CSVs in der deutschen Lokalisierung korrekt, Komma-CSVs nicht — was bei manueller Nachbearbeitung zu falsch interpretierten Spalten führt. Wer den Export an ein Tool weitergibt, sollte das Zielformat kennen, nicht das Ausgangsformat.
Varianten-Handling: Die Entscheidung, ob Varianten als Eltern oder Kinder exportiert werden, muss vor dem ersten Lauf fallen. Ein nachträglicher Wechsel bricht jedes bestehende Mapping.
Custom Fields: Sie erscheinen als JSON-String in einer einzigen Spalte. Marktplätze können damit nichts anfangen. Wer regelmäßig exportiert, sollte Custom Fields in eigene Spalten auflösen — per API-Transformation oder in der Middleware.
Inkrementelle Logik: Ein Voll-Export pro Tag ist bei Katalogen über 10.000 SKUs verschwenderisch und fehleranfällig. Der updatedAt-Filter ist 2026 die Standardmethode für alles, was nicht ein initialer Vollabgleich ist.
Die nüchterne Empfehlung: Wer nur gelegentlich eine CSV für Reporting oder Archivierung braucht, bleibt beim Standard-Export. Wer regelmäßig Daten an externe Systeme liefert, kommt um API-gestützte Pipelines oder Middleware nicht herum. Die entscheidende Frage ist nicht, ob der native Export funktioniert — er tut es. Die Frage ist, ob man den manuellen Aufwand pro Zielsystem dauerhaft tragen will. Bei einem Marktplatz vielleicht. Bei dreien wird es zur Vollzeitstelle.