Seit Adobe die Storefront-API von Magento 2 auf GraphQL umstellt, bewegt sich der Datenverkehr aus dem Shop effizient und flexibel. Der umgekehrte Weg bleibt bis heute eine Baustelle: Wer Produkte, Kunden oder Bestände per GraphQL in Magento 2 Open Source oder Adobe Commerce importieren will, stößt nativ auf eine Wand. Die mitgelieferten Mutations decken Warenkorb, Checkout und Kundenkonto ab – Bulk-Importe gehören nicht dazu.
Die Community arbeitet seit Jahren daran, GraphQL zum vollwertigen Ersatz für die REST-API auszubauen. 2026 ist der Stand klar: Für Lesezugriffe ist GraphQL der Standard, für den Datenimport bleibt REST mit seinen CSV- und Bulk-Endpunkten das Werkzeug der Wahl. Ein neues Tutorial aus dem Firebear-Umfeld zeigt nun, wie Händler die Lücke praktisch schließen – und wo die Grenzen liegen.
Warum kann Magento 2 GraphQL keine Importe?
Die Antwort liegt in der Architektur. GraphQL in Adobe Commerce wurde für Storefront-Abfragen gebaut: Produktdaten für Headless-Frontends, Preise für PWAs, Kategorien für Mobile-Apps. Die Mutation-Abdeckung wuchs zwar mit jeder Version, konzentrierte sich aber auf kundenbezogene Vorgänge – Artikel in den Warenkorb legen, Adressen anlegen, Bestellungen auslösen.
Ein Import von 50.000 SKUs hat damit nichts zu tun. Er verlangt Transaktionssicherheit, Chunking, Validierung und Rollback-Logik – Aufgaben, für die Adobes Bulk-API über REST ausgelegt ist. Wer GraphQL dafür umbiegt, läuft in Timeout-Grenzen und Lastprobleme, die das Framework nicht abfedert.
Wer den Datenimport per GraphQL in Magento 2 angeht, sollte die Erwartung mitbringen, einen Workaround zu bauen – kein natives Feature zu konfigurieren.
Welche Wege führen 2026 zum GraphQL-Import?
Drei Optionen stehen im Raum. Erstens der bewährte Pfad: REST-Bulk-Endpoints für die Masse der Daten, GraphQL nur dort, wo das Frontend liest. Das ist die Konstellation, die Adobe selbst in der Dokumentation empfiehlt, und sie funktioniert stabil bis in sehr große Kataloge.
Zweitens: Eigene Mutation-Resolver schreiben. Entwickler können im Modul etc/schema.graphqls eigene Einstiegspunkte definieren und dahinter Import-Logik hängen. Das klappt für definierte Einzelfälle – etwa eine Preisaktualisierung pro SKU aus einem PIM –, skaliert aber nicht zu echten Massendaten. Wer diesen Weg geht, muss Queue-Verarbeitung und Fehlerbehandlung selbst bauen.
Drittens die Extension-Lösung: Firebears Improved Import & Export ergänzt GraphQL-Unterstützung für Import- und Export-Jobs und deckt damit genau die Lücke ab, die der Core offen lässt. Für Agenturen mit wiederkehrenden Datenanbindungen an mehrere Magento-Instanzen ist das der pragmatischste Weg, statt pro Projekt Custom-Resolver zu pflegen. Die Extension ist kein Kleinstpreis, amortisiert sich aber schnell gegenüber Eigenentwicklung.
Was bedeutet das für den Shop-Alltag?
Für Shopbetreiber ab einer Million Euro Umsatz ändert sich kurzfristig wenig: Bestehende PIM-, ERP- und Wawi-Anbindungen über REST oder CSV laufen weiter. Die strategische Frage taucht bei Neuaufbauten auf. Wer jetzt eine Headless-Architektur mit Hyvä, PWA Studio oder einem externen Frontend plant, sollte GraphQL für alle Lesezugriffe nutzen – und den Import bewusst auf REST oder eine Import-Extension legen, statt auf GraphQL-Support aus dem Core zu warten.
Ein Blick in die Roadmap lohnt: Adobe hat GraphQL in den letzten Releases konsequent erweitert, zuletzt vor allem im B2B-Bereich mit Company- und Quote-Abfragen. Dass Import-Mutations dazukommen, ist wahrscheinlich – ein Datum gibt es nicht.
Handlungsimpuls: Prüfen Sie bei der nächsten Integrationsentscheidung, ob Ihre Agentur Importe noch über CSV-Cronjobs abbildet. REST-Bulk oder eine Import-Extension mit API-Layer sind der sauberere Stand – und der Wechsel kostet weniger, als die meisten befürchten.