73 Prozent der deutschen Mittelständler mit eigenem Onlineshop pflegen Produktdaten noch mindestens teilweise per Hand oder CSV-Upload nach — so das Ergebnis einer Befragung des E-Commerce-Verbandes bevh aus dem vergangenen Jahr. Wer Magento Open Source oder Adobe Commerce betreibt, hat dafür eigentlich keine Ausrede mehr: Die REST API des Systems ist der offizielle, dokumentierte und mächtigste Weg, um Artikel, Preise, Bestände und Kunden zwischen Shop und Umsystemen auszutauschen. Trotzdem enden unzählige Integrationsprojekte in Skript-Friedhöfen, die bei jedem Versionssprung brechen.
Der Grund liegt selten in der API selbst. Er liegt in Entscheidungen, die lange vor der ersten Zeile Code fallen: welcher Endpoint, welches Authentifizierungsmodell, welche Architektur. Genau dort setzt dieser Artikel an.
Was kann die Magento 2 REST API beim Import wirklich leisten?
Die kurze Antwort: praktisch alles, was der Admin-Bereich hergibt — und mehr. Über die REST-Schnittstelle lassen sich Produkte, Kategorien, Kunden, Bestellungen, Lagerbestände und CMS-Inhalte anlegen, aktualisieren und löschen. Adobe pflegt die Schemas als OpenAPI-Spezifikation, das heißt: Maschinenlesbar, versioniert, ohne Reverse Engineering.
Die lange Antwort ist unangenehmer. Die API ist ein CRUD-Werkzeug, kein Import-Werkzeug. Wer 40.000 Artikel über einzelne POST /V1/products-Calls schiebt, erzeugt 40.000 HTTP-Requests mit jeweils eigener Authentifizierung, eigener Validierung, eigenem Datenbank-Commit. Auf einer typischen Shopware-müde gewordenen Agentur-VM dauert das Stunden. Auf einer gut dimensionierten Adobe-Commerce-Cloud-Instanz immer noch spürbar länger als nötig.
Ein zweites Missverständnis betrifft die Richtung. Viele Projekte behandeln die API als Einbahnstraße: ERP schiebt rein, Shop nimmt an. In der Praxis brauchen Händler beide Richtungen — Bestellungen raus, Bestände rein, Retourenstatus zurück. Wer das nicht von Anfang an plant, baut zwei parallele Integrationen statt einer bidirektionalen.
Warum scheitern so viele Import-Integrationen am ersten Tag?
Am Token-Handling, nicht an der Datenlogik. Magento kennt drei Authentifizierungswege: Admin-Token, Customer-Token und OAuth. Für Server-zu-Server-Integrationen ist der Integrations-Token der richtige Weg — angelegt unter System » Extensions » Integrations, mit sauber eingeschränkten Ressourcen-Rechten. Was man stattdessen in Produktivsystemen findet, sind Admin-Benutzer mit Vollrechten, deren Credentials in Cron-Skripten auf demselben Server liegen wie der Shop selbst.
Das zweite klassische Scheitern-Muster: keine Idempotenz. Ein Import-Lauf bricht bei Artikel 12.400 ab. Das Skript startet neu — und legt 12.399 Artikel doppelt an, weil es Updates von Inserts nicht unterscheidet. Die REST API gibt mit PUT /V1/products/:sku ein natives Upsert-Verhalten her, das genau dieses Problem löst. Man muss es nur benutzen.
Die teuerste API-Integration ist die, die beim ersten Fehler nicht weiß, wo sie aufgehört hat.
Und dann gibt es das Rechteproblem. Eine Integration, die „alles“ darf, wird früher oder später auch alles kaputt machen. Adobe erlaubt im Integrations-Backend eine feingranulare Zuordnung auf Ressourcenebene — Produkte ja, Bestellungen nein, Konfiguration niemals. In Audits deutscher Shop-Projekte findet man diese Einschränkung selten. Das ist kein Schönheitsfehler, sondern ein Sicherheitsrisiko mit Haftungsfolgen, spätestens wenn personenbezogene Kundendaten im Spiel sind.
Bulk-Endpoints: Der Unterschied zwischen Stunden und Minuten
Seit Magento 2.3 existiert mit /async/bulk/V1/products ein asynchroner Import-Weg, der in deutschen Projekten auffallend selten genutzt wird. Statt einzelner Requests schickt die Integration Batches — etwa 1.000 Produkte pro Aufruf — in eine Message Queue. Magento verarbeitet sie im Hintergrund über RabbitMQ, die Integration bekommt eine Bulk-UUID zurück und fragt den Status später ab.
Faktor 10 bis 50 schneller ist das in der Praxis, gemessen an Projekten mit 20.000 bis 100.000 SKUs. Der Flaschenhals wandert vom HTTP-Overhead in die Datenbank — und die lässt sich mit Indexer-Management und sauberem Schedule steuern. Wichtig: Nach dem Import laufen die Indexer. Wer sie auf „Update on Save“ stehen lässt, bremst jeden Bulk-Lauf aus. „Update by Schedule“ plus anschließendem gezielten Reindex ist der produktive Standard.
Ehrlicherweise gehört zur Vollständigkeit: Für echte Erstbefüllungen mit sechsstelligen Artikelzahlen ist selbst die Bulk-API nicht das schnellste Instrument. Wer einmalig 300.000 Produkte aus einem PIM migriert, fährt mit dem nativen Import-Modul über CSV oder mit direkten Datenbank-Tools schneller. Die REST API gewinnt dort, wo Import ein Dauerzustand ist — tägliche Preisupdates, stündliche Bestandssynchronisation, laufende Produktdatenpflege aus dem ERP.
Wie binden deutsche Händler ERP und Warenwirtschaft an?
Im DACH-Markt lautet die realistische Antwort: selten direkt, fast immer über Middleware. Die typische Landschaft sieht so aus — SAP Business One oder Microsoft Dynamics 365 als ERP, dazu eine Warenwirtschaft wie JTL-Wawi oder Xentral, daneben vielleicht ein PIM wie Akeneo oder Contentserv. Jede dieser Welten spricht ein anderes Datenformat, und keine davon spricht nativ Magento-REST.
Deshalb haben sich Integrationsplattformen etabliert, die genau diese Übersetzung leisten:
- Actindo und Tradebyte im Enterprise- und Marktplatz-Umfeld, mit fertigen Adobe-Commerce-Konnektoren
- Synesty und ähnliche iPaaS-Tools im Mittelstand, die REST-Calls, CSV-Exporte und Datenbankabfragen orchestrieren
- Eigenentwicklungen auf Basis von Symfony oder Node.js dort, wo Agenturen das Datenmapping ohnehin individuell bauen müssen
Meine redaktionelle Einschätzung nach einem Dutzend solcher Projekte: Die Middleware-Frage ist wichtiger als die API-Frage. Ein sauber gemapptes Synesty-Szenario, das Preise alle 15 Minuten über die Bulk-API schiebt, schlägt jede handgeschriebene Direktanbindung — weil es Wartung, Monitoring und Fehlerbehandlung mitliefert. Die API ist die Straße. Ohne Fahrplan nützt sie nichts.
Adobe Commerce oder Open Source — macht das einen Unterschied beim Import?
Beim REST-Kern kaum. Die Endpoint-Struktur, die Authentifizierung, die Bulk-Mechanik: identisch, weil beide auf demselben Framework sitzen. Wer eine Integration für Magento Open Source 2.4 baut, kann sie in der Regel unverändert gegen Adobe Commerce fahren.
Die Unterschiede liegen im Umfeld. Adobe Commerce on Cloud bringt RabbitMQ als gemanagten Service mit — unter Open Source muss der Hoster oder der Betreiber selbst für die Queue sorgen, inklusive Monitoring und Neustart-Strategie. Klingt nach Kleinkram, ist es nicht: Eine stehengebliebene Consumer-Prozess-Kette ist der häufigste Grund, warum „die API nicht mehr importiert“, obwohl die API einwandfrei läuft. Die Requests landen brav in der Queue, nur konsumiert sie niemand mehr.
Dazu kommen Commerce-exklusive Endpoints, etwa für B2B-Company-Strukturen, Shared Catalogs und Preislisten. Wer B2B-Händler mit kundenindividuellen Preisen ist — im deutschen Mittelstand die Regel, nicht die Ausnahme — muss prüfen, ob das Preismodell überhaupt auf Open Source abbildbar ist, bevor die erste Integrationsstunde verbrannt wird.
Betrieb, Monitoring und die Frage nach dem Notfallplan
Eine Import-Integration ist keine Projektphase, sie ist ein Dauerbetrieb. Drei Dinge gehören zum Mindeststandard, werden aber regelmäßig vergessen: ein Monitoring auf Bulk-UUID-Ebene, das fehlgeschlagene Batches alarmiert statt sie verstummen zu lassen; ein Token-Rotationskonzept, damit Integrations-Zugänge nicht jahrelang unverändert in Config-Dateien liegen; und ein dokumentierter Wiederanlauf, der nach einem Abbruch exakt weitermacht, wo der letzte erfolgreiche Batch endete.
Was Händler jetzt konkret tun sollten: den eigenen Datenfluss aufschreiben — Quellsystem, Ziel, Frequenz, Volumen. Dann prüfen, ob der aktuelle Import überhaupt die Bulk-Endpoints nutzt oder noch Request für Request werkelt. Und schließlich die Rechte der bestehenden Integrationen auditieren. Wer dort Vollzugriff findet, hat nicht nur ein Effizienzproblem gelöst bekommen, sondern eines geschaffen.
Die nächste Eskalationsstufe ist absehbar: Adobe baut seine Commerce-Plattform Richtung API-first und App Builder aus, die Edge-Delivery-Architektur verschiebt weitere Logik aus dem Kern. Händler, die ihre Datenflüsse heute sauber über die REST API organisiert haben, werden diesen Umbau als Migration erleben. Alle anderen als Neuanfang.