Wer Produktdaten in Magento 2 oder Adobe Commerce importieren will, stößt 2026 auf eine offene Baustelle: Die GraphQL-API, von Adobe seit Jahren als moderner Nachfolger der REST-API positioniert, beherrscht den Datenimport bis heute nicht out of the box. Wer den Weg trotzdem gehen will, braucht Eigenentwicklung oder Community-Lösungen – und sollte genau wissen, was dabei technisch passiert.
Warum beherrscht Magento 2 den GraphQL-Import nicht von Haus aus?
GraphQL wurde im Magento-Ökosystem primär als Lese-API konzipiert. Storefront-Abfragen für Produkte, Kategorien und Preise laufen darüber längst performant – Stichwort Headless-Commerce und PWA Studio. Schreibende Operationen, sogenannte Mutations, decken dagegen vor allem Kundenkonten, Warenkörbe und den Checkout ab. Der Massenimport von Produkten, Attributen oder Lagerbeständen blieb bisher der klassischen REST-API und dem CSV-basierten Import-Modul vorbehalten.
Die Community arbeitet an einer Schließung dieser Lücke. Ziel ist es, GraphQL mittelfristig als vollwertigen REST-Ersatz zu etablieren – inklusive bidirektionalem Datenaustausch. Bis das im Core landet, setzen Agenturen auf eigene Mutation-Resolver, die über das GraphQL-Schema von Magento 2 registriert werden und intern auf die bewährten Import-Schnittstellen zugreifen.
Wie funktioniert der Import über GraphQL-Mutations technisch?
Die Antwort in einem Satz: Entwickler definieren eine eigene Mutation im Schema, verknüpfen sie mit einem Resolver und kapseln darin die eigentliche Import-Logik. Konkret läuft das über die Datei schema.graphqls im eigenen Modul. Dort wird etwa eine Mutation importProducts deklariert, die ein Array von Produktdaten entgegennimmt. Der zugehörige Resolver validiert die Eingaben, mappt sie auf die Magento-Entitäten und schreibt sie über das Produkt-Repository in die Datenbank.
Für den Export funktioniert das Prinzip spiegelverkehrt: Eine Query liefert die gewünschten Datensätze strukturiert zurück – mit dem entscheidenden GraphQL-Vorteil, dass der Client exakt die Felder anfordert, die er braucht. Kein Overfetching wie bei REST, wo jede Antwort das komplette Objekt mitliefert. Bei einem Katalog mit 50.000 Artikeln und komplexen Attributsets macht das messbar etwas aus: weniger Payload, weniger Parsing-Aufwand auf beiden Seiten.
GraphQL löst beim Datenexport ein reales Problem: Händler ziehen nur die Felder ab, die sie tatsächlich weiterverarbeiten – statt kompletter Produktobjekte mit Dutzenden ungenutzten Attributen.
Was bedeutet das für Shopbetreiber im Alltag?
Für den täglichen Betrieb ändert sich vorerst wenig. Wer Warenwirtschaft, PIM-Systeme wie Akeneo oder Preisfeeds anbindet, fährt mit REST oder dem CSV-Import weiterhin stabil. Der GraphQL-Weg lohnt sich dort, wo ohnehin eine Headless-Architektur existiert und das Entwicklerteam die Schnittstellen konsolidieren will – eine API für Lese- und Schreibzugriffe statt zweier paralleler Welten.
Zu bedenken ist die Kehrseite: Eigene Mutations bedeuten eigenen Code, der bei Core-Updates gepflegt werden muss. Adobe Commerce 2.4.8 und die Open-Source-Pendants bringen regelmäßig Änderungen am GraphQL-Schema mit; Resolver, die auf interne Klassen zugreifen, sollten nach jedem Minor-Release getestet werden. Wer das nicht leisten kann, wartet besser ab, bis die Community-Lösungen reifen.
Beobachtenswert bleibt, wie schnell Adobe und die Community die Import-Lücke im Core schließen. Wer heute eine neue Systemanbindung plant, sollte die Schnittstelle so abstrahieren, dass ein späterer Wechsel von REST zu GraphQL ohne Neuentwicklung der gesamten Integration möglich ist.