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.