Wer Bestellungen über die Shopify Admin API importiert und dabei mehrere Pakete pro Bestellung verschickt, kennt den Umweg: Fulfillment anlegen, danach erneut anfassen, um die restlichen Tracking-Nummern nachzutragen. Dieser zweite API-Call entfällt jetzt. Shopify hat das Feld trackingNumbers zum Input-Objekt OrderCreateFulfillmentInput ergänzt – Sendungsverfolgungsnummern lassen sich damit direkt beim Anlegen der Bestellung über die orderCreate-Mutation mitliefern.
Die Änderung klingt klein, trifft aber einen Alltagsschmerz vieler Shopbetreiber. Gerade Händler mit sperriger Ware, Multi-Item-Bestellungen oder Teillieferungen aus verschiedenen Lagern versenden regelmäßig zwei, drei oder mehr Pakete pro Order. Bisher hieß das im Import-Szenario: erst die Bestellung inklusive Fulfillment erzeugen, dann über eine separate Mutation die zusätzlichen Nummern anhängen. Jeder dieser Schritte kostet API-Aufrufe, Fehleranfälligkeit und Zeit.
Was ändert sich konkret bei der orderCreate-Mutation?
Neu ist ausschließlich das Feld trackingNumbers in OrderCreateFulfillmentInput. Statt einer einzelnen Nummer akzeptiert der Input nun eine Liste von Sendungsnummern, die beim Erstellen des Fulfillments in einem Rutsch übergeben werden. Die Antwort bleibt kompatibel: Bestehende Integrationen, die weiterhin nur eine Nummer übergeben, laufen unverändert weiter.
Für Entwickler bedeutet das weniger Orchestrierung im eigenen Code. Wer bisher eine Warteschleife oder einen zweiten Request gebaut hatte, um Tracking-Daten nachzuladen, kann diesen Zweig streichen. Das reduziert auch die Gefahr inkonsistenter Zustände – etwa wenn der erste Call erfolgreich war, der zweite aber an einem Rate Limit oder Timeout scheiterte und der Kunde im Tracking-Portal nur ein Paket sah.
Warum betrifft das vor allem Händler mit eigener Warenwirtschaft?
Die orderCreate-Mutation wird vor allem von Händlern genutzt, die Bestellungen aus externen Systemen in Shopify spiegeln: ERP-Anbindungen, Warenwirtschaften wie JTL, plentymarkets oder Xentral, Marktplatz-Integrationen oder selbstgebaute Middleware. Genau in diesen Setups entstehen Mehrpaket-Sendungen automatisch – die Warenwirtschaft entscheidet erst beim Pickvorgang, wie viele Kartons eine Bestellung braucht.
Ein Beispiel aus der Praxis: Ein Möbelhändler importiert täglich Bestellungen aus seinem ERP nach Shopify. Eine Kommode geht als Sperrgut in zwei Paketen raus, der passende Beistelltisch als drittes Paket mit DHL. Bisher musste die Integration das Fulfillment erstellen und anschließend zweimal aktualisieren. Mit dem neuen Feld wandern alle drei Nummern in den initialen Request – und der Kunde sieht in seiner Bestellstatus-Mail und im Shop-Kundenkonto von Anfang an die komplette Sendung.
Die Antwort auf die Frage, wer profitiert, ist damit klar: Jeder, der orderCreate zum Import nutzt und mehr als ein Paket pro Bestellung verschickt. Wer Bestellungen direkt im Shop erzeugt und über das Admin-Backend oder Fulfillment-Apps abwickelt, merkt von der Änderung nichts – dort gab es Mehrfach-Tracking schon länger.
Handlungsimpuls für Shopbetreiber und Agenturen
Entwickler sollten ihre Import-Integrationen gegen das aktuelle Admin-API-Schema prüfen und das neue Feld dort einsetzen, wo bisher Follow-up-Requests gebaut wurden. Wer eine fertige Middleware zwischen Warenwirtschaft und Shopify einsetzt, fragt am besten beim Anbieter nach, ob die Anbindung das Feld bereits nutzt – bei JTL- oder plentymarkets-Connector-Lösungen ist das ein sinnvoller Punkt für das nächste Update-Ticket.
Einen Haken gibt es dennoch: Die Änderung betrifft nur den Import-Pfad über orderCreate. Fulfillments, die nachträglich um Pakete wachsen – etwa weil eine Teillieferung erst Tage später rausgeht – müssen weiterhin über die üblichen Fulfillment-Update-Mutationen ergänzt werden. Das neue Feld erspart den zweiten Call nur beim initialen Anlegen, nicht im laufenden Versandprozess.
Für Shopify bleibt die Richtung erkennbar: Die Plattform räumt seit Monaten konsequent kleine Reibungspunkte in den API-Workflows für Händler mit komplexer Logistik ab. Wer seine Integration ohnehin anfasst, sollte den Umbau jetzt mitnehmen – die Einsparung an API-Calls und Fehlerquellen ist real, der Aufwand überschaubar.