Ein 40-Fuß-Container aus Shenzhen ist 32 Tage unterwegs. Der Händler weiß davon in Echtzeit — 31 davon. Am 33. Tag steht die Ware nicht im Lager, sondern im Hamburger Terminal, blockiert durch eine Zollprüfung, von der niemand im ERP etwas mitbekommt. Das ist der Zustand, den die Rede vom „digitalen Container-Tracking“ gerne verschweigt.
Hapag-Lloyd, fünftgrößte Containerreederei der Welt mit Sitz in Hamburg, betreibt sein Tracking by Container seit Jahren als API-first-Produkt. Es löst genau dieses Problem — bis zu einem gewissen Punkt. Der Teufel steckt in der Frage, welche Ereignisse die Reederei automatisiert weitergibt und welche der Händler selbst nachfassen muss.
Was das Hapag-Lloyd Tracking technisch tatsächlich liefert
Die Hapag-Lloyd API (Track & Trace) gibt in Version 2 strukturierte JSON-Antworten auf Containernummer, Booking-Nummer oder Bill of Lading. Jeder Container erhält einen Statusverlauf mit Zeitstempel, Location-Code (UN/LOCODE) und Event-Typ. Zu den rund 25 dokumentierten Event-Codes gehören Loaded, Discharged, Gate In, Gate Out, Empty Return und Transshipment.
Das ist erheblich präziser als die Web-Oberfläche, die Ad-hoc-News-Leser unter dem Begriff „digitale Sendungsverfolgung“ kennen. Der Unterschied: In der API stehen Rohdaten, auf der Website stehen interpretierte Sätze. Wer Tracking in sein OMS integriert, arbeitet mit den Rohdaten — und muss selbst interpretieren.
Genau darin liegt die häufigste Fehlannahme im E-Commerce. Tracking-Systeme werden eingekauft, als seien sie Sensoren am Container. Tatsächlich sind sie Meldeketten zwischen Reederei, Terminal, Agent und Spediteur. Jedes Glied kann verzögern.
Warum verlieren Händler trotz Tracking den Überblick?
Weil die Dateninseln nicht zusammenwachsen. Ein deutscher Möbelhändler, der über Hapag-Lloyd aus Vietnam importiert, hat drei Informationsquellen: die Reederei-API, das Terminal Operating System (bei Hamburg etwa das Hafenbetriebssystem von HHLA) und den Spediteur, der mit eigener Software hantiert. Keine dieser Quellen kennt die anderen.
Die Folge sind doppelte Status. Gate Out erscheint in der Reederei-API, wenn der Container das Terminal verlässt — aber nicht, wenn der Spediteur ihn einen Tag später ins Lager bringt. Der Händler sieht Ware als „unterwegs“, obwohl sie auf dem Hof steht. Oder umgekehrt: Er storniert Nachbestellungen, weil das Tracking „noch auf See“ meldet, während die Ware längst im Zentrallager liegt.
Laut einer 2024er Erhebung des Branchenverbands BVL gaben 61 Prozent der befragten Handels- und Industrieunternehmen an, Lieferverzögerungen im Seefrachtbereich erst mit mehr als 24 Stunden Verzug in ihren Systemen zu sehen. Das ist die Lücke, die zwischen „wir haben Tracking“ und „wir wissen, wo die Ware ist“ klafft.
Wie funktioniert die Integration in gängige Shop- und ERP-Systeme?
Praktisch läuft es über einen Polling- oder Webhook-Dienst. Der Händler registriert seine Container-IDs bei einem Middleware-Anbieter wie Shippeo, project44, FourKites oder einem spezialisierten DACH-Dienstleister. Die Middleware zieht in definierten Intervallen die Hapag-Lloyd-API ab, normalisiert die Events und schreibt sie ins OMS oder ERP — idealerweise mit Bezug zur Bestellposition.
Erst dieser letzte Schritt macht Tracking kommerziell relevant. Solange ein Status nur in einem Reederei-Portal steht, hat er für den Kundenservice kaum Wert. Sobald er an die Bestellung gekoppelt ist, lassen sich drei Dinge automatisieren, die direkt auf Marge wirken:
- Kundenkommunikation mit belastbarem Lieferdatum statt vager „voraussichtlich“-Angaben
- Lagerdisposition und Sicherheitsbestände, die den tatsächlichen Ankunftstag kennen
- Cashflow-Steuerung, weil Akkreditive und Zahlungsziele an Discharged-Events gekoppelt werden können
Punkt drei unterschätzen die meisten. Wer auf Rechnung mit 60 Tagen importiert und den Zahlungszeitpunkt an die tatsächliche Ankunft knüpft, gewinnt Liquiditätsspielraum — oder verliert ihn, wenn das Tracking ungenau ist.
Seefracht-Tracking wird erst dann zum Steuerungsinstrument, wenn es nicht mehr der Reederei dient, sondern der Bestellung.
Welche Grenzen hat Hapag-Lloyd Tracking — und wann braucht es mehr?
Die Reederei-API endet an der Wasserkante des Hafens. Kein Hapag-Lloyd-System weiß, ob die Ware nach dem Gate Out in Duisburg, München oder Rotterdam landet. Für die letzte Meile braucht der Händler eine zweite Datenquelle — meist den Spediteur oder den Landverkehrsdienstleister.
Zweite Grenze: Multi-Carrier. Wer 2026 nur mit Hapag-Lloyd fährt, hat Glück. Die meisten größeren Importeure splitten auf Maersk, MSC, CMA CGM, Evergreen. Deren APIs unterscheiden sich in Struktur, Event-Vokabular und Aktualisierungsfrequenz. Wer fünf Reedereien einzeln anbindet, baut fünf Datenmodelle. Der Aufwand treibt Händler zu Middleware — mit entsprechenden Kosten, die je nach Volumen fünf- bis sechsstellig im Jahr erreichen können.
Dritte Gren