Fulfillment anbinden ohne Copy-Paste: Schnittstellen richtig nutzen

Jede Bestellung von Hand an den Fulfiller schicken kostet dich pro Woche Stunden. Und der erste Zahlendreher in einer Adresse kostet dich einen Kunden.

Ich habe diese Anbindung für nano., mate und MUSTAX gebaut, dazu für eine Reihe Flowhouse-Kunden. Der Aufbau ist jedes Mal ähnlich. Die Fehler sind es auch. Deshalb hier der Ablauf, den ich inzwischen immer nehme, mit den Stellen, an denen es in der Praxis knallt.

Was zwischen Shop und Lager wirklich fließt

Bevor du irgendein Tool anfasst, schreib auf, welche Daten in welche Richtung laufen. Es sind genau zwei Richtungen und ein paar wenige Ereignisse.

Vom Shop zum Lager:

• Der Auftrag: Bestellnummer, Positionen mit SKU (die eindeutige Artikelnummer) und Menge, Lieferadresse, gewünschte Versandart.
• Änderungen am Auftrag, solange er noch nicht gepackt ist.
• Der Stornowunsch.

Vom Lager zurück zum Shop:

• Die Versandbestätigung mit Carrier, Tracking-Nummer und den tatsächlich versendeten Positionen.
• Der aktuelle Bestand je SKU.
• Der Wareneingang einer Retoure.

Das war es. Alles andere ist Kür. Wer diese Liste nicht sauber hat, baut eine Schnittstelle, die im Normalfall funktioniert und im Sonderfall schweigt.

Ein Punkt fällt fast immer hinten runter: der Bestand. Wenn du auf mehreren Kanälen verkaufst, ist die Rückmeldung aus dem Lager deine einzige Wahrheit. Wie wir das aufgebaut haben, steht in Bestandsführung Multichannel.

Dateiübergabe oder Schnittstelle: die Abwägung

Viele Fulfiller bieten beides an. CSV-Dateien per SFTP (ein Dateiserver mit Verschlüsselung) oder eine API (eine Programmierschnittstelle, über die Systeme direkt miteinander sprechen).

Meine Faustregel: Unter 20 Bestellungen am Tag und mit einem Fulfiller, der nur CSV kann, ist die Dateiübergabe völlig in Ordnung. Sobald Kunden nach Tracking fragen, bevor deine Datei überhaupt gelaufen ist, wird die API zur besseren Wahl.

Der unterschätzte Nachteil der Datei ist nicht die Verzögerung. Es ist die Stille. Eine kaputte Zeile in einer CSV wird beim Fulfiller kommentarlos übersprungen, und du merkst es drei Tage später an einer Kundenmail. Eine API antwortet dir sofort mit einem Fehlercode.

Die Ereignisse, auf die du reagierst

Der saubere Weg ist ereignisgetrieben, nicht zeitgesteuert. Shopify schickt dir eine Nachricht, sobald etwas passiert. Das nennt sich Webhook. Falls dir der Begriff nichts sagt: In Webhooks erklärt ist das in zehn Minuten durch.

Drei Webhooks reichen für den Anfang:

• `orders/paid`: Auftrag ist bezahlt, darf ins Lager.
• `orders/cancelled`: Stornoversuch, so schnell wie möglich ans Lager.
• `orders/updated`: Adresse oder Positionen haben sich geändert.

Auf der Gegenseite brauchst du eine Adresse, an die der Fulfiller seine Versandmeldung schicken kann. Kann er das nicht, fragst du seine Schnittstelle alle 15 Minuten nach neuen Sendungen. Das ist unschön, aber funktioniert.

Zwischen beiden Seiten sitzt bei uns n8n. Es nimmt den Webhook an, übersetzt die Felder und ruft die Gegenseite auf. Wenn du damit noch nie gearbeitet hast: Dein erster n8n-Workflow ist der kürzeste Einstieg. Wie das komplette Bestellsystem bei uns aussieht, steht in Order Processing ohne Mitarbeiter.

Die Felder, an denen es scheitert

Die Übersetzung zwischen Shop und Lager ist der Teil, den alle unterschätzen. Vier Klassiker aus unserer eigenen Anbindung:

SKUs stimmen nicht überein. Im Shop heißt der Artikel `NANO-BLK-2ER`, im Lager `1004237`. Du brauchst eine Zuordnungstabelle, und zwar an genau einer Stelle. Nicht in drei Workflows verteilt.

Bundles gibt es im Lager nicht. Dein Zweierpack ist im Shop ein Artikel, im Lager sind es zwei. Löse das beim Übersetzen, nicht im Lagerbestand.

Adressfelder passen nicht. Shopify hat `address1` und `address2`, viele Lagersysteme trennen Straße und Hausnummer. Ein automatisches Zerlegen der Straße geht bei etwa jeder zwanzigsten deutschen Adresse schief. Frag lieber die Hausnummer im Checkout separat ab oder lass den Fulfiller zerlegen.

Versandarten heißen überall anders. `Standard` bei dir, `DHL_PAKET_NATIONAL` beim Lager. Auch das gehört in die Zuordnungstabelle.

Fehlerfälle, die dich später einholen

Der Normalfall ist in einem Tag gebaut. Die restlichen Tage gehen für diese vier Fälle drauf, und genau die entscheiden, ob dein Support ruhig bleibt.

Teillieferung. Das Lager hat nur zwei von drei Positionen da und schickt trotzdem los. Wenn deine Anbindung die Bestellung dann pauschal als komplett versendet markiert, bekommt der Kunde eine Tracking-Nummer für ein Paket, in dem sein Lieblingsartikel fehlt. Übernimm immer die tatsächlich versendeten Positionen aus der Rückmeldung, nie die ursprüngliche Bestellung.

Stornierung nach Übergabe. Zwischen "Kunde storniert" und "Paket ist gepackt" liegen bei einem guten Fulfiller manchmal 20 Minuten. Dein Storno-Aufruf muss drei Antworten verkraften: storniert, zu spät, unbekannt. Bei "zu spät" musst du den Fall als Retoure führen und darfst nicht einfach Geld erstatten.

Doppelte Übergabe. Webhooks kommen manchmal zweimal an, das ist normal und kein Fehler. Schick deshalb immer die Bestellnummer als eindeutigen Schlüssel mit und lass den Fulfiller ablehnen, was er schon kennt. Ohne das versendest du irgendwann ein Paket doppelt.

Adressänderung im Rennen. Der Kunde schreibt zwei Stunden nach Bestellung. Bei uns darf die Automatik das nicht selbst entscheiden. Der Workflow prüft, ob das Paket schon gepackt ist, und legt den Fall dann einem Menschen vor.

Diese vier Fälle machen zusammen vielleicht drei Prozent der Bestellungen aus. Sie machen aber den Großteil der Support-Mails aus, die danach hereinkommen.

So testest du, bevor echte Ware rausgeht

Testen heißt nicht, eine Bestellung durchzuschicken und zufrieden zu sein. Das ist die Reihenfolge, die ich immer nehme:

1. Testumgebung anfragen. Fast jeder Fulfiller hat eine. Wenn nicht, vereinbare eine Test-SKU, die nie versendet wird.

2. Ein Auftrag mit einer Position. Prüfe Feld für Feld gegen das, was im Lagersystem ankommt. Nicht nur "ist angekommen".

3. Ein Auftrag mit Bundle, Sonderzeichen und langer Adresse. Umlaute, Apostrophe und ein Firmenname mit 60 Zeichen decken die meisten Formatfehler auf.

4. Die vier Fehlerfälle von oben, einzeln. Jeden bewusst auslösen und schauen, was dein System tut.

5. Rückweg prüfen. Tracking-Nummer landet in Shopify, Kunde bekommt genau eine Mail, nicht drei.

6. Erste Woche mit Schattenbetrieb. Automatik läuft, ein Mensch schaut jeden Abend zehn Minuten drüber.

Wenn dir die API-Begriffe in der Doku deines Fulfillers fremd sind, hilft API-Grundlagen für E-Commerce beim Lesen.

Datenschutz: Adressen sind personenbezogene Daten

Sobald du Namen und Adressen an den Fulfiller gibst, verarbeitest du personenbezogene Daten im Auftrag. Drei Dinge gehören geregelt, bevor die erste echte Bestellung fließt.

Auftragsverarbeitungsvertrag. Jeder Fulfiller braucht einen, und jedes Zwischensystem auch. Wenn dein n8n bei einem Hoster läuft, gehört der ebenfalls in dein Verzeichnis der Verarbeitungstätigkeiten.

Serverstandort. Bei uns läuft n8n selbst gehostet in Deutschland. Das ist kein Muss, aber es macht die Auskunft an Kunden kurz.

Sparsamkeit und Aufbewahrung. Der Fulfiller braucht Name, Adresse, Positionen. Er braucht keine Zahlungsdaten, keine Bestellhistorie, keine Marketing-Einwilligung. Und deine Workflow-Protokolle sollten Klarnamen nicht monatelang aufheben. Wir löschen Ausführungsdaten nach 30 Tagen.

Die Grenzen

Damit du dir das nicht schönredest:

• Eine Schnittstelle repariert keinen schlechten Fulfiller. Wenn dort falsch gepackt wird, siehst du es danach nur schneller.
• Sonderfälle bleiben Handarbeit. Ein Paket im Zoll, eine falsche Charge, ein B2B-Auftrag mit Palettenversand: dafür lohnt kein Workflow.
• Der Aufbau dauert länger als der Normalfall vermuten lässt. Rechne für eine ordentliche API-Anbindung mit 3 bis 8 Tagen, nicht mit einem Nachmittag.
• Du brauchst Überwachung. Ein Workflow, der still ausfällt, ist schlimmer als Handarbeit. Bei uns meldet Slack jeden fehlgeschlagenen Durchlauf sofort.

Fazit

Die Anbindung selbst ist nicht schwer. Schwer ist die Sorgfalt davor: Welche Daten fließen, wie heißen die Felder auf beiden Seiten, was passiert bei Teillieferung und Storno.

Wenn du diese Liste vor dem Bauen abarbeitest, läuft die Anbindung danach jahrelang ohne dich. Wenn nicht, hast du Copy-Paste durch stille Fehler ersetzt, und das ist kein guter Tausch.

Falls du deine Fulfiller-Doku vor dir liegen hast und nicht sicher bist, ob API oder Datei die richtige Wahl ist: schreib uns kurz über Flowhouse. Wir schauen uns das an, ohne Pitch.