How OOCL Container Tracking Actually Works: What the Portal Shows, What It Doesn't, and What the Events Mean

Key Takeaways

OOCL uses the most verbose event labels of any carrier. “Discharged from Vessel at Last Port of Discharge” is OOCL’s way of saying “Discharged.” Every label is descriptive to the point of being unwieldy.
OOCL is not a DCSA member. Instead, it participates in the GSBN blockchain consortium for data standards and electronic documentation.
There is no public REST API. All programmatic tracking runs through EDI (UN/EDIFACT, ANSI-X.12, XML) via CargoSmart and SFTP/AS2/SMTP protocols. This is the least modern integration path among the top-12 carriers.
My OOCL Center (MOC) is the registered-user platform and includes a Control Tower with predictive analytics, SmartDoc for AI-powered shipping instructions, and D&D free-time expiry alerts up to 5 days in advance.
Schedule reliability was highly volatile in 2025: 46.6% in January, rising to 83.3% mid-year (highest among the top 13 carriers), before declining again.
OOCL is a COSCO subsidiary (since July 2018), but the two brands operate entirely separate tracking systems, portals, and booking platforms.
Container prefixes are limited: OOLU (standard dry, ~350,000 units) and OOCU (reefer), plus approximately 150,000 non-OOLU leased containers.

Schedule reliability figures, update cadence estimates, and carrier performance data referenced in this guide are based on third-party industry reports and may reflect specific monthly snapshots rather than sustained averages. Carrier systems and capabilities are subject to change.

Who This Is For

This guide is for freight forwarders, importers, and operations teams who track on OOCL and need to decode its verbose event labels, understand why there is no REST API, and navigate the My OOCL Center platform. For the cross-carrier comparison showing how OOCL’s labels differ from every other carrier, see our event naming guide.

What the Portal Shows You

OOCL’s primary tracking platform is My OOCL Center (MOC) at moc.digital.oocl.com. Public tracking is also available without login for basic container lookups. MOC is the feature-rich registered platform that provides the full suite of tracking, documentation, and analytics tools.

MOC is significantly more capable than most carrier portals. Beyond basic milestone tracking, it includes a Control Tower with predictive analytics that flags shipments at risk of delay, SmartDoc for AI-powered shipping instruction submission, FreightSmart for quotation and booking, and eBL capabilities via IQAX and GSBN. If you are an OOCL customer and still tracking through the basic public lookup, you are leaving functionality on the table.

D&D free-time expiry alerts up to 5 days in advance are available through MOC. This is a valuable feature that most carriers do not offer — it means you get advance warning before demurrage or detention charges begin, rather than finding out after charges have already started accruing.

OOCL also pushes booking-change notifications: vessel changes, routing changes, and cargo quantity changes are communicated proactively. Combined with the milestone notifications, this gives OOCL one of the most complete proactive notification systems among carriers.

Container prefixes include OOLU and OOCU. OOLU covers the standard dry fleet of approximately 350,000 units, while OOCU is used for reefer containers. OOCL also operates approximately 150,000 non-OOLU leased containers that may have various third-party prefixes. All are trackable through MOC. For identifier guidance, see our identifier guide.

Event Names and What They Mean

OOCL’s event labels are the most verbose in the industry. Where Maersk says “Loaded on Vessel” and MSC says “Loaded (at POL),” OOCL says “Loaded on Board at First Port of Load.” This verbosity eliminates ambiguity but makes cross-carrier normalization more labor-intensive.

OOCL Event Label	What Actually Happened	DCSA Code
Full Container Received by Carrier at Origin	Laden container entered the origin terminal (Gate In)	—
Loaded on Board at First Port of Load	Container was lifted onto the vessel at port of loading	—
Discharged at Port of Transshipment	Container unloaded at the transshipment hub	—
Loaded on Board at Port of Transshipment	Container loaded onto connecting vessel at hub	—
Discharged from Vessel at Last Port of Discharge	Container unloaded from the vessel at final destination	—
Picked up at Final Destination for Delivery	Container left the terminal (Gate Out)	—
Empty Container Returned to Carrier at Destination	Empty container returned to depot	—
Estimated Date of Arrival Changed at Last Port of Discharge	ETA revision alert (exception event, not a physical milestone)	—

Every DCSA code column is blank. OOCL is not a DCSA member and does not use DCSA event codes. The labels are self-descriptive enough that mapping is straightforward — “Loaded on Board at First Port of Load” is obviously the LOAD event — but the mapping is your responsibility if you are building multi-carrier integrations.

The “Estimated Date of Arrival Changed” alert is an exception event, not a physical milestone. It fires when OOCL revises the ETA for the final destination. This is a useful proactive notification — most carriers update their ETAs silently, and you only notice when you check the portal. OOCL explicitly alerts you to the change.

Transshipment events are broken out. OOCL publishes separate “Discharged at Port of Transshipment” and “Loaded on Board at Port of Transshipment” events, giving you visibility into whether the container is sitting at the hub or has been loaded onto the next vessel. This is in line with Hapag-Lloyd, Evergreen, and ZIM — and better than CMA CGM or ONE.

OOCL also publishes booking-change notifications including vessel changes, routing changes, and cargo quantity changes. These are not part of the standard milestone timeline but are communicated through MOC’s notification system. If your vessel or routing changes mid-voyage, OOCL will tell you — you do not have to discover it by comparing ETAs.

Update Cadence: How Fresh Is the Data?

OOCL’s data freshness is competitive with top-tier carriers. Milestone events typically appear within 2-8 hours of occurring, powered by OOCL’s CargoSmart data infrastructure. CargoSmart, launched in 2000 with OOCL as a founding investor, provides the underlying data processing for OOCL’s tracking and EDI systems.

The Control Tower in MOC adds a predictive layer. Rather than just showing what has happened, the Control Tower flags shipments that are at risk of delay based on current vessel positions, port congestion data, and historical patterns. This predictive capability means you can act on potential problems before the milestone event fires — or fails to fire.

The D&D free-time alerts fire up to 5 days before expiry. This early warning is time-stamped and delivered through MOC’s notification system, giving operations teams a window to arrange pickup or negotiate extensions before charges start accruing.

Known Gaps and Quirks

No REST API. This is OOCL’s most significant digital limitation. While Maersk, CMA CGM, Hapag-Lloyd, ONE, ZIM, and Evergreen all offer REST APIs (with varying levels of accessibility), OOCL provides only EDI-based integration. The supported formats are UN/EDIFACT, ANSI-X.12, and XML, delivered via SFTP, AS2, or SMTP through the CargoSmart platform. EDI is reliable and proven, but it is also slow to set up, expensive to maintain, and requires specialized middleware that many modern logistics teams do not have.

Not a DCSA member. OOCL participates in the GSBN (Global Shipping Business Network) blockchain consortium instead. GSBN handles documentation standards and eBL capabilities through IQAX (an OOIL subsidiary). In March 2025, OOCL completed its first cross-platform eBL transaction via IQAX/ICE/GSBN. While GSBN is a legitimate standards initiative, it is separate from the DCSA ecosystem that most other major carriers have adopted. For multi-carrier integrations, OOCL’s non-DCSA data requires custom mapping alongside COSCO and Wan Hai.

Verbose labels complicate normalization. “Full Container Received by Carrier at Origin” is unambiguous, but it is also unique. No other carrier uses this label. If you are normalizing tracking data across 10+ carriers, OOCL’s labels are always the longest and always need to be mapped individually. The descriptive naming helps humans read the timeline but increases the engineering cost of automated processing.

Schedule reliability was extremely volatile in 2025. OOCL hit 46.6% in January 2025 and 83.3% mid-year — a 37-point swing. The mid-year high was the best among all top-13 carriers. The January low was among the worst. This volatility makes OOCL ETAs particularly hard to calibrate: during high-reliability periods, the portal ETAs are genuinely useful; during low-reliability periods, they are barely directional.

Separate from COSCO despite the ownership. Despite being a COSCO subsidiary since July 2018 (acquired by Faulkner Global Holdings, which holds approximately 71.07%), OOCL maintains completely independent tracking, booking, and documentation systems. An OOLU container cannot be tracked on COSCO’s portal, and a COSU container cannot be tracked on OOCL’s. If you ship on both, you are managing two independent workflows with two different event naming schemes — one verbose (OOCL), one proprietary (COSCO First POL/Last POD).

Middle East disruptions affected OOCL. During the Hormuz crisis, OOCL suspended Middle East bookings and implemented an Emergency Bunker Surcharge. In-transit containers on affected routes may show unusual gaps or rerouting events in the tracking timeline.

What to Do When Tracking Breaks

Scenario 1: “Estimated Date of Arrival Changed” alert received. This is not a malfunction — it is OOCL’s proactive ETA revision notification. Check the updated date on the tracking page. If the revision is significant (3+ days), the vessel may have been rerouted or delayed. Contact OOCL for details on the cause.

Scenario 2: Trying to build a REST API integration. OOCL does not have one. Your options are: (1) EDI via CargoSmart (SFTP/AS2/SMTP), which requires specialized setup, or (2) a third-party visibility platform that has already built the OOCL integration and exposes it through their own API. For most modern logistics teams, option 2 is faster and cheaper to implement.

Scenario 3: Container with non-OOLU prefix not found on OOCL portal. OOCL operates approximately 150,000 leased containers that may have third-party prefixes. If a container you expected to be OOCL equipment does not resolve by prefix, try searching by B/L or booking reference instead.

Scenario 4: D&D free-time alert received — what do I do? OOCL’s alerts fire up to 5 days before free time expires. Use this window to arrange container pickup, confirm trucker availability, and verify that all releases (customs, freight) are in place. If you need an extension, contact OOCL’s local office before the free time expires — extending after charges begin is significantly harder.

Scenario 5: Trying to cross-reference an OOCL shipment with a COSCO booking. The two systems are completely independent. If a shipment involves both OOCL and COSCO (for example, an Ocean Alliance routing where the container moves on a COSCO-operated vessel for one leg), the tracking data will come from whichever carrier issued the booking. You will not find cross-references between the portals.

API and Integration Options

OOCL does not offer a public REST API. This makes it unique among the top-12 carriers, all of whom have at least some form of REST-based tracking interface (even if gated behind sales reps or beta labels). OOCL’s programmatic integration path is EDI only.

EDI runs through CargoSmart, a Hong Kong-based logistics technology company launched in 2000 with OOCL as a founding investor and developer (CargoSmart operates independently rather than as an OOCL subsidiary). Supported formats include UN/EDIFACT, ANSI-X.12, and XML. Data delivery uses SFTP, AS2, or SMTP protocols. Setting up an EDI integration with OOCL requires establishing a CargoSmart connection, mapping OOCL’s verbose event labels to your internal event model, and maintaining the EDI middleware. This is expensive and slow compared to a REST API integration.

GSBN handles documentation rather than tracking. The Global Shipping Business Network blockchain consortium focuses on electronic documentation — bills of lading, certificates — rather than real-time tracking. IQAX, an OOIL subsidiary, powers eBL capabilities. In March 2025, OOCL completed its first cross-platform eBL via IQAX/ICE/GSBN. These are documentation advances, not tracking advances.

For modern tracking integrations, the practical advice is: use a third-party visibility platform that has already built the OOCL connection. Platforms like Vizion, Terminal49, and project44 offer REST APIs that include OOCL data, letting you avoid the EDI setup entirely. The trade-off is adding a vendor dependency, but for most teams the time-to-integration difference between building OOCL EDI from scratch and plugging into a visibility platform is measured in months.

Operational Note: OOCL’s My OOCL Center is one of the most feature-rich carrier platforms in the industry — the Control Tower, D&D alerts, booking-change notifications, and SmartDoc capabilities make it a genuinely useful operational tool. The irony is that the platform is excellent for human users but inaccessible for automated systems due to the lack of a REST API. If you are managing OOCL shipments manually through MOC, you have better tools than most carriers provide. If you need to integrate OOCL tracking into your systems, you face a harder path than with any other top-12 carrier.