Seit Version 2.3 ist GraphQL fester Bestandteil von Magento 2, als Abfragesprache für PWA-Storefronts und Headless-Frontends hat sich die API längst durchgesetzt. Doch wer Produktdaten, Kunden oder Bestellungen in den Shop schreiben will, stößt auch 2026 auf dieselbe Grenze: Ein nativer Import über GraphQL existiert weder in Magento Open Source noch in Adobe Commerce. Ein aktuelles Entwickler-Tutorial zeigt nun, welche Wege trotzdem funktionieren, und wo Shopbetreiber aufpassen müssen.
Warum kann Magento 2 GraphQL nicht nativ importieren?
Die kurze Antwort: Adobe hat GraphQL in Magento als Read-API für Storefronts konzipiert, nicht als Schreibschnittstelle für den Katalog. Die im Core verfügbaren Mutations decken Warenkorb, Checkout, Kundenkonto und zunehmend B2B-Funktionen wie Verhandlungsangebote ab. Produkt- oder Bestandsdaten anlegen lässt sich darüber nicht. Für den Massenimport bleiben deshalb zwei native Pfade: die REST API mit ihren asynchronen Bulk-Endpunkten und der klassische CSV-Import im Backend.
Technisch ist die Entscheidung nachvollziehbar. GraphQL-Mutations im Admin-Bereich müssten Validierung, Indexierung und die Verarbeitung großer Datenmengen abbilden, Aufgaben, für die die Bulk-REST-Endpunkte mit Message-Queue-Anbindung bereits gebaut wurden. Adobe investiert seine GraphQL-Ressourcen sichtbar in die Storefront-Abdeckung, jeder 2.4.x-Release der vergangenen Jahre erweiterte vor allem Queries und Checkout-Mutations.
Wie lässt sich der GraphQL-Import trotzdem umsetzen?
Zwei Wege haben sich in der Praxis etabliert. Entwickler mit eigenem Team definieren eigene Mutations über schema.graphqls und registrieren Resolver in der etc/graphql/di.xml ihres Moduls. Das funktioniert sauber für klar umrissene Fälle, etwa das Anlegen einzelner Produkte aus einem PIM, wird aber bei Tausenden Datensätzen schnell teuer, weil Queue-Verarbeitung und Fehlerbehandlung selbst gebaut werden müssen.
Schneller geht es über die Community. Die Extension Improved Import & Export von FireBear Studio, seit Jahren eine der meistgenutzten Import-Lösungen im Magento-Ökosystem, bringt GraphQL-basierte Import- und Export-Profile mit und bindet damit auch Quellen an, die kein REST sprechen. Für Händler ohne eigene Entwicklungskapazität ist das der pragmatischste Einstieg. Wer ohnehin eine Middleware wie einen iPaaS-Connector zwischen ERP und Shop betreibt, sollte prüfen, welchen Pfad der Konnektor nutzt, die meisten setzen weiterhin auf REST, und das ist auch vertretbar.
GraphQL-Import in Magento ist kein Core-Feature, sondern ein Architektur-Entscheid: Eigenbau, Extension oder beim bewährten REST-Bulk bleiben.
Was bedeutet das für den Shop-Alltag?
Für laufende Integrationen ändert sich nichts. REST und die Bulk-Endpunkte bleiben supported und sind für hohe Datenvolumina weiterhin die erste Wahl, vorausgesetzt, RabbitMQ oder der Queue-Consumer laufen stabil. Handlungsbedarf gibt es an zwei Stellen. Erstens: Wer ein Headless-Frontend neu aufsetzt, sollte die Datenflüsse früh trennen, GraphQL für alles, was der Shop liest, REST oder Extension für alles, was geschrieben wird. Zweitens lohnt ein Blick in die Fehlerlogs bestehender Import-Jobs: Viele selbstgebaute CSV-Schleifen lassen sich auf die asynchronen Bulk-Endpunkte migrieren und gewinnen damit Wiederanlauf- und Lastverhalten.
Die Richtung der Community ist klar: Mit jedem Headless-Projekt wächst der Druck, GraphQL auch schreibend vollwertig zu machen. Bis Adobe das im Core liefert, wenn überhaupt, gilt: Stabile REST-Integrationen nicht vorschnell abreißen, aber bei Neubauten die API-Strategie bewusst wählen. Wer heute weiß, welche Daten über welchen Kanal fließen, muss morgen nicht zweimal integrieren.