API und EDI-Schnittstellen

Im Fulfillment entscheidet die Qualität der Systemanbindung darüber, ob Bestellungen ohne manuelle Eingriffe ins Lager fließen, Bestände korrekt angezeigt werden und Kunden rechtzeitig Tracking-Informationen erhalten. API-Schnittstellen und EDI (Electronic Data Interchange) sind die beiden zentralen Technologien, mit denen Shop, ERP, WMS, Versanddienstleister und 3PL-Partner miteinander kommunizieren. Wer die Unterschiede, Einsatzgebiete und typischen Fallstricke kennt, trifft die richtige Integrationsentscheidung – und vermeidet teure Nacharbeit in der Hochsaison.

Warum Schnittstellen im Fulfillment unverzichtbar sind

Jede Bestellung durchläuft eine Kette digitaler Systeme: Der Kunde bestellt im Shop, das OMS priorisiert und verteilt Aufträge, das WMS steuert Pick und Pack, die Carrier-API erzeugt Labels, und das ERP bucht Warenbewegungen. Ohne automatisierte Schnittstellen bleibt an jeder Übergabe ein manueller Schritt – CSV-Exporte, Copy-Paste von Tracking-Nummern oder telefonische Bestandsabfragen beim Lager.

Typische Probleme bei fehlender oder schlechter Integration:

  1. Überverkäufe, weil Shop-Bestände Stunden oder Tage hinter dem Lagerbestand liegen.
  2. Verspätete Versandbestätigungen, die Marktplatz-SLAs verletzen und Strafgebühren auslösen.
  3. Doppelte Dateneingabe in Shop, WMS und ERP mit steigender Fehlerquote.
  4. Fehlende Rückverfolgbarkeit, wenn bei Reklamationen unklar ist, welches System welche Version einer Bestellung gespeichert hat.

Fulfillment-Schnittstellen-Stack

Vier horizontale Ebenen von oben nach unten – mit bidirektionalen Verbindungslinien zwischen allen Ebenen (grün für Echtzeit-API, blau für EDI-Batch):

1. Vertrieb

Shop, Marktplätze – REST-API, Webhooks

2. Steuerung

OMS, Middleware – Event-basierte Weiterleitung

3. Ausführung

WMS, 3PL – API oder EDI für Aufträge und Bestände

4. Backoffice

ERP, Finanz – EDI oder Batch-API für Buchungen

Grundlagen zur Gesamtarchitektur findest du im Artikel ERP und Shop-Anbindung.

API und EDI – Definition und Abgrenzung

Was ist eine API-Schnittstelle?

Eine Application Programming Interface (API) ermöglicht den programmatischen Datenaustausch zwischen Systemen in Echtzeit oder nahezu Echtzeit. Im E-Commerce-Fulfillment dominieren REST-APIs (HTTP-Requests mit JSON-Payload) und zunehmend GraphQL bei modernen Shop-Systemen wie Shopify. Webhooks ergänzen Pull-basierte APIs: Sobald ein Ereignis eintritt (neue Bestellung, Versandstatus), pusht das Quellsystem die Information an den Empfänger.

Typische API-Anwendungen im Fulfillment:

  • Bestellungen vom Shop an WMS oder 3PL übertragen
  • Verfügbare Bestände vom Lager an Shop und Marktplätze melden
  • Versandlabels über Carrier-APIs erzeugen
  • Tracking-Nummern zurück an Shop und Kundenkommunikation senden

Was ist EDI?

EDI (Electronic Data Interchange) ist ein standardisierter, oft batch-orientierter Datenaustausch zwischen Unternehmen. Statt individueller JSON-Strukturen nutzen Partner fest definierte Nachrichtentypen – häufig nach UN/EDIFACT oder branchenspezifischen Formaten wie ODETTE im Automotive-Bereich. Übertragung erfolgt typischerweise über AS2, SFTP oder VAN-Dienste (Value Added Network).

EDI ist besonders verbreitet bei:

  • Großhandel und B2B-Abnehmer mit festen EDI-Verträgen
  • Lieferantenkommunikation (Bestellungen, ASN)
  • Konzern-ERP-Systemen (SAP, Oracle) im Enterprise-Umfeld
  • Retail-Ketten mit vorgegebenen EDI-Spezifikationen

API vs. EDI im direkten Vergleich

Kriterium
API (REST/Webhooks)
EDI (EDIFACT/AS2)
Latenz
Sekunden bis Minuten (Echtzeit)
Minuten bis Stunden (Batch-Zyklen)
Flexibilität
Individuell pro System, schnell anpassbar
Strenge Standards, Änderungen aufwändig
Typische Partner
Shops, WMS, 3PL, Carrier, Marktplätze
Großhandel, Retail-Ketten, Enterprise-ERP
Implementierungsaufwand
Mittel – abhängig von API-Dokumentation
Hoch – Mapping, Zertifizierung, Testphasen
Skalierung E-Commerce
Ideal für hohe Order-Volumen und Multi-Channel
Bei reinem D2C oft überdimensioniert
Fehlerbehandlung
HTTP-Statuscodes, Retry-Logik, Dead-Letter-Queues
Functional Acknowledgement (CONTRL), manuelle Klärung

API vs. EDI Einsatzgebiete

API – E-Commerce/D2C

Shop, WMS, Carrier – Echtzeit-Pfeile, hohe Flexibilität und Skalierbarkeit für Multi-Channel-Setups.

EDI – B2B/Enterprise

Großhandel, ERP, Retail – Batch-Pfeile in festen Intervallen, standardisierte Nachrichtentypen nach EDIFACT.

Wichtig: Die meisten E-Commerce-Händler mit eigenem Lager oder 3PL-Partner arbeiten primär mit APIs. EDI wird relevant, sobald B2B-Großkunden, Retail-Anbindungen oder Enterprise-ERP-Systeme ins Spiel kommen – oft parallel zu API-basierten Shop-Integrationen.

Zentrale Datenflüsse über Schnittstellen

Bestellungen (Outbound vom Shop)

Sobald eine Kundenbestellung bezahlt und freigegeben ist, muss sie an das ausführende System (eigenes WMS oder 3PL) übermittelt werden. Über die Schnittstelle fließen mindestens:

  1. Auftragsnummer und Bestelldatum
  2. Artikelpositionen mit SKU, Menge und ggf. Chargenangaben
  3. Lieferadresse und Kontaktdaten
  4. Versandart und Priorität (Standard, Express)
  5. Zahlungsstatus und ggf. Rechnungsreferenz

Bei Multi-Channel-Setups bündelt ein OMS die Aufträge aus verschiedenen Quellen, bevor sie an das WMS gehen. Details zur Shop-Anbindung findest du im Kapitel Multi-Channel Fulfillment.

Bestandsmeldungen (Inbound zum Shop)

Das WMS oder der 3PL-Partner meldet verfügbare Mengen zurück. Entscheidend ist die Synchronisationsfrequenz: Bei schnelldrehenden Artikeln reicht ein nächtlicher Batch-Import nicht aus. API-basierte Echtzeit-Sync oder mindestens stündliche Updates verhindern Überverkäufe.

Versandbestätigungen und Tracking

Nach dem Packvorgang sendet das WMS Versanddaten an Shop und OMS:

  • Sendungsnummer und Carrier
  • Versanddatum und voraussichtliche Zustellung
  • Paketgewicht und Abmessungen (für Kostencontrolling)

Diese Daten triggern Kunden-E-Mails und Marktplatz-Updates. Verzögerungen hier sind eine der häufigsten Ursachen für schlechte Bewertungen.

Wareneingang und ASN

Bei Lieferantenware informiert eine Advance Shipping Notice (ASN) das Lager vorab über ankommende Sendungen. Je nach Partner erfolgt das per EDI-Nachrichtentyp DESADV oder per API-Webhook. So kann das Lager Kapazitäten planen und Wareneingänge beschleunigen.

Order-to-Ship über Schnittstellen

1
Bestellung im Shop
2
API-Webhook an OMS
3
Pick-Auftrag ans WMS (typische Fehlerstelle: SKU-Mapping)
4
Kommissionierung
5
Label via Carrier-API
6
Tracking zurück an Shop

Shop-Systeme und ihre API-Landschaft

Die drei häufigsten Shop-Plattformen im deutschsprachigen Raum bieten unterschiedliche API-Reifegrade. Ein ausführlicher Vergleich steht im Artikel Shopify WooCommerce Shopware.

Plattform
API-Typ
Webhooks
Fulfillment-Apps
Shopify
REST + GraphQL Admin API
orders/create, fulfillments/create
Großes 3PL-/WMS-Ökosystem
WooCommerce
REST API (Plugin-abhängig)
Über Hooks oder Middleware
Plugin-basiert, Qualität variiert
Shopware
Admin API + Store API
Native Events (OrderPlaced, etc.)
Starke DACH-Partner (Pickware)

EDI-Standards im Fulfillment-Kontext

Für Händler, die neben D2C auch B2B beliefern, sind folgende EDI-Nachrichtentypen relevant:

EDIFACT-Typ
Bedeutung
Fulfillment-Bezug
ORDERS
Bestellung
B2B-Kundenauftrag an Händler
ORDRSP
Bestellbestätigung
Auftragsbestätigung mit Liefertermin
DESADV
Lieferavis (ASN)
Ankündigung Wareneingang ans Lager
INVOIC
Rechnung
Abrechnung nach Versand
RECADV
Wareneingangsbestätigung
Rückmeldung eingelagerte Mengen

Die technische Anbindung erfolgt meist über einen EDI-Dienstleister oder eine Middleware, die EDI-Nachrichten in API-Calls für das interne WMS übersetzt. Das reduziert den direkten EDI-Aufwand im WMS, behält aber die B2B-Konformität bei.

Tipp: Prüfe bei B2B-Kunden frühzeitig, ob EDI verpflichtend ist und welche Spezifikationsversion (D.96A, D.01B etc.) gefordert wird. EDI-Projekte dauern oft 3–6 Monate inklusive Test- und Zertifizierungsphase.

Middleware und iPaaS als Integrations-Schicht

Statt jede Systemkombination individuell zu programmieren, setzen viele Händler auf Middleware oder iPaaS-Lösungen (Integration Platform as a Service). Diese Plattformen bieten vorkonfigurierte Konnektoren für Shop, WMS, ERP und Marktplätze und übernehmen:

  • Datenmapping zwischen unterschiedlichen Feldstrukturen
  • Fehlerbehandlung mit Wiederholungslogik und Alerting
  • Transformation von EDI in JSON und umgekehrt
  • Monitoring aller Integrations-Jobs an einem Dashboard

Bekannte Lösungen im DACH-Raum sind unter anderem Billbee, ChannelEngine, Pickware Connect und Weclapp. Bei der technischen Anbindung eines 3PL-Partners solltest du klären, ob Middleware bereits im Angebot enthalten ist oder separat budgetiert werden muss.

Integrationsprojekt strukturiert planen

Phase 1: Anforderungsanalyse

  1. Welche Systeme müssen verbunden werden (Shop, WMS, ERP, Carrier, 3PL)?
  2. Welche Datenflüsse sind kritisch (Orders, Bestand, Tracking, Retouren)?
  3. Welche Latenz ist fachlich erforderlich (Echtzeit vs. Batch)?
  4. Gibt es B2B-Partner mit EDI-Pflicht?
  5. Welche Auftragsvolumen und Peak-Szenarien sind zu erwarten?

Phase 2: Technische Spezifikation

  • API-Dokumentation aller beteiligten Systeme einholen
  • Feld-Mapping-Tabellen erstellen (Shop-SKU ↔ WMS-SKU ↔ ERP-Artikelnummer)
  • Fehler- und Retry-Strategie definieren
  • Testumgebung (Sandbox) bei allen Partnern anfordern

Phase 3: Entwicklung und Test

  • Unit-Tests für Mapping-Logik
  • End-to-End-Tests mit echten Testbestellungen
  • Lasttests vor Peak-Saisons (Black Friday, Weihnachten)
  • Parallelbetrieb mit manuellem Fallback während der Übergangsphase

Phase 4: Go-Live und Monitoring

Ein Go-Live ohne Monitoring ist riskant. Richte von Anfang an Alerts ein, wenn Schnittstellen-Aufrufe fehlschlagen, Queues wachsen oder Bestandsabweichungen zwischen Shop und Lager auftreten.

Integrationsprojekt – Zeitplan

1
Analyse (ca. 2 Wochen)
2
Spezifikation (ca. 3 Wochen)
3
Entwicklung/Test (6–12 Wochen) – kritischster Abschnitt
4
Go-Live + Monitoring (laufend)

Häufige Fehlerquellen und Gegenmaßnahmen

SKU-Inkonsistenzen sind der häufigste Integrationsfehler. Shop, WMS und ERP verwenden unterschiedliche Artikelnummern, und das Mapping bricht bei neuen Produkten oder Varianten. Lösung: zentrale Stammdatenverwaltung im ERP mit eindeutiger SKU als Master.

Fehlende Idempotenz bei API-Calls führt zu Doppelaufträgen, wenn Webhooks mehrfach ausgelöst werden. Jede Nachricht braucht eine eindeutige Referenz-ID, und das empfangende System muss Duplikate erkennen.

Kein Dead-Letter-Handling: Fehlgeschlagene Nachrichten verschwinden in Logs, statt in einer Warteschlange für manuelle Nachbearbeitung zu landen.

Unterschätzte Peak-Last: APIs, die bei 50 Orders/Tag stabil laufen, brechen bei 2.000 Orders/Tag in der Black-Week zusammen. Lasttests sind Pflicht.

Weitere Integrationsdetails findest du in WMS-Integration.

Praxis-Checkliste: Schnittstellen vor Go-Live

  • Feld-Mapping für alle Artikelnummern (SKU, EAN, ERP-Nr.) dokumentiert und getestet
  • Testbestellung End-to-End durch alle Systeme erfolgreich
  • Bestands-Sync-Frequenz definiert und im Peak getestet
  • Tracking-Rückmeldung an Shop und Marktplätze verifiziert
  • Stornierungs- und Teilversand-Flows implementiert
  • Retouren-Rückbuchung an Shop getestet
  • Fehler-Alerts (E-Mail, Slack, Monitoring-Dashboard) aktiv
  • Retry-Logik für temporäre API-Fehler konfiguriert
  • Dead-Letter-Queue für fehlgeschlagene Nachrichten eingerichtet
  • API-Rate-Limits aller Partner dokumentiert und berücksichtigt
  • Fallback-Prozess bei Schnittstellen-Ausfall schriftlich definiert
  • Datenschutz (DSGVO) bei Kundenadress-Übertragung geprüft

Sicherheit und Compliance

Schnittstellen übertragen personenbezogene Daten (Kundenadressen, E-Mail) und geschäftskritische Informationen. Beachte:

  1. Verschlüsselung: HTTPS/TLS für alle API-Verbindungen, AS2 mit Signatur und Verschlüsselung für EDI
  2. Authentifizierung: OAuth 2.0, API-Keys mit minimalen Berechtigungen, regelmäßiger Key-Rotation
  3. Auftragsverarbeitung: Bei 3PL-Partnern AV-Vertrag gemäß DSGVO abschließen
  4. Logging: Personenbezogene Daten in Logs minimieren oder pseudonymisieren
  5. Zugriffskontrolle: Nur benötigte Endpunkte freischalten, IP-Whitelisting wo möglich

Typische Ausfallursachen bei Integrations-Ausfällen

Ursache
Anteil
SKU-Mapping
35 %
Timeout/Rate-Limit
25 %
Fehlende Webhook-Retries
20 %
Manuelle Eingriffe
15 %
Sonstige
5 %

Unternehmen mit aktivem Monitoring reduzieren Integrations-Ausfälle signifikant – der Trend zeigt nach unten bei konsequentem Alerting und Dead-Letter-Handling.

Fazit: Die richtige Schnittstellen-Strategie wählen

Für den typischen E-Commerce-Händler mit Shop, WMS und Carrier-Anbindung sind REST-APIs mit Webhooks der Standard – flexibel, schnell und gut skalierbar. EDI ergänzt das Setup, sobald B2B-Großkunden oder Enterprise-ERP-Partner feste EDI-Anforderungen stellen. In beiden Fällen gilt: Investition in sauberes Mapping, robustes Fehlerhandling und kontinuierliches Monitoring zahlt sich schneller aus als manuelle Workarounds in der Hochsaison.

Verwandte Themen

Letzte Aktualisierung: 7. Juli 2026