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

Key Takeaways

COSCO is not a DCSA member. Unlike Maersk, CMA CGM, Hapag-Lloyd, ONE, and most other major carriers, COSCO has not adopted the DCSA data standard.
Event labels follow a unique “First POL / Last POD / T/S” convention that differs from every other carrier. “Loaded at First POL” and “Discharged at Last POD” are distinctive COSCO terminology.
API access requires a 15-day review process with HMAC-SHA1 authentication, 1,000 calls per day, and 30,000 per month limits.
OOCL is a COSCO subsidiary (since July 2018), but the two brands operate separate tracking systems and separate portals.
Schedule reliability runs 50-60%, roughly in line with CMA CGM and below the global average.

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.

What the Portal Shows You

The portal accepts container numbers, B/L numbers, and booking references. No login is required for basic container lookups. The interface is available in English, though some label translations are awkward — a legacy of the portal being designed primarily for the Chinese market.

Container prefixes include COSU (primary), CBHU, CCLU, and CSNU. All are searchable on the same portal. COSCO operates one of the world’s largest fleets, and the container prefix variety reflects both owned and leased equipment. For guidance on whether to track by container number or B/L, see our identifier guide.

COSCO and OOCL are separate tracking systems. Even though COSCO acquired OOCL in July 2018, the two brands maintain independent tracking portals, independent container prefixes, and independent booking systems. An OOLU container will not resolve on COSCO’s portal, and a COSU container will not resolve on OOCL’s. If you ship on both, you are managing two completely separate tracking workflows.

Event Names and What They Mean

COSCO’s event naming is unique among major carriers. Where most carriers use “POL” and “POD” (Port of Loading / Port of Discharge), COSCO uses “First POL,” “Last POD,” and “T/S POL / T/S POD” to distinguish between origin, destination, and transshipment legs. This convention is distinctive and takes some getting used to.

COSCO Event Label	What Actually Happened	DCSA Code
Gate-in at First POL	Laden container entered the origin terminal	—
Loaded at First POL	Container was lifted onto the vessel at port of loading	—
Departure from First POL	Vessel left the port of loading	—
Discharged at T/S POD	Container unloaded at the transshipment port	—
Loaded at T/S POL	Container loaded onto the connecting vessel at the hub	—
Arrival at Last POD	Vessel arrived at the final destination port	—
Discharged at Last POD	Container unloaded from the vessel at destination	—
Gate-out at Last POD	Container left the destination terminal	—

Every DCSA code column is blank. COSCO is not a DCSA member, so none of these events map to official DCSA codes. If you are building multi-carrier integrations that rely on DCSA normalization, COSCO data requires a custom mapping layer. The event labels are close enough to be mapped — “Loaded at First POL” clearly corresponds to the DCSA LOAD event — but the mapping is your responsibility, not COSCO’s.

The “First POL / Last POD” convention is actually useful for transshipment clarity. While the naming is different from other carriers, it does make one thing unambiguous: you always know whether an event occurred at the origin (“First POL”), the transshipment hub (“T/S”), or the destination (“Last POD”). On carriers that reuse the same labels for both transshipment and destination events, you have to check the port name to tell the difference. COSCO’s labeling handles that disambiguation automatically.

Transshipment events are broken out. COSCO publishes separate “Discharged at T/S POD” and “Loaded at T/S POL” events, giving you visibility into whether a container has been offloaded at the hub and when it was loaded onto the connecting vessel. This is better transshipment granularity than CMA CGM or ONE, though it does not eliminate the dwell-time blind spot between the discharge and reload events.

Update Cadence: How Fresh Is the Data?

COSCO’s data freshness is difficult to benchmark precisely because the company does not publish its update frequency in the way that CMA CGM or Maersk do. Based on observed behavior through third-party visibility platforms, tracking events typically appear 4-12 hours after the physical milestone, with backend synchronization running multiple times per day.

The Vue.js portal renders data dynamically, which means the page always fetches the latest available data from COSCO’s backend when you load it. There is no caching layer between you and the source data — but the source data itself is only as fresh as the terminal’s latest upload to COSCO’s system.

Silence between departure and arrival events is standard. COSCO does not provide mid-ocean position updates. Once you see “Departure from First POL,” the next event will be either a transshipment milestone or “Arrival at Last POD,” depending on the routing. Gaps of 10-20 days on transpacific voyages are normal. Our guide on why tracking stops updating explains when silence is expected versus concerning.

Known Gaps and Quirks

Not a DCSA member. This is the most significant structural gap. While Maersk, CMA CGM, Hapag-Lloyd, ONE, ZIM, Evergreen, and HMM have all adopted DCSA standards to varying degrees, COSCO has not. This means COSCO’s tracking data uses proprietary event labels, proprietary data structures, and does not conform to the industry’s push toward standardization. For multi-carrier integrations, COSCO is always the carrier that requires custom handling.

The portal blocks automated access by design. The Vue.js SPA architecture means that HTTP-level tools (curl, wget, simple scrapers) get an empty HTML shell. Browser automation tools (Selenium, Playwright) can render the page, but COSCO may block these with rate limiting or bot detection. The API is the intended programmatic access path.

No “Available for Pickup” event. Like most carriers, COSCO does not publish a combined availability event. After “Discharged at Last POD,” the tracking timeline jumps to “Gate-out at Last POD” with no indication of customs status, freight hold status, or terminal availability in between.

Ocean Alliance routing adds partner-vessel complexity. COSCO is part of the Ocean Alliance with CMA CGM, OOCL, and Evergreen, extended through 2032. Containers booked on COSCO may travel on alliance partner vessels. Tracking data from partner-operated legs can be delayed or less granular than data from COSCO’s own vessels.

Schedule reliability runs 50-60%. COSCO’s on-time performance in 2025 hovered in the same range as CMA CGM and below the global average. Roughly 4-5 out of 10 arrivals deviate from the published schedule. ETAs in the portal should be treated as rough estimates, particularly for routings with transshipment connections.

Middle East disruptions. COSCO suspended all new Middle East bookings during the Hormuz crisis, which affected tracking for in-transit shipments on those routes. If you are tracking a COSCO container originally routed through the Middle East and the timeline shows unusual gaps or reroutings, the Hormuz suspension may be the cause.

No empty return visibility. COSCO’s public tracking does not consistently surface empty return events. After “Gate-out at Last POD,” the tracking timeline typically ends. If you need proof of timely empty return for detention disputes, the Equipment Interchange Receipt (EIR) from the depot is the necessary documentation — COSCO’s portal will not provide it.

What to Do When Tracking Breaks

Scenario 1: Portal loads but shows no tracking data. COSCO’s Vue.js portal requires JavaScript to render any content. Disable ad blockers, ensure JavaScript is enabled, and clear your browser cache. If the page renders a layout but the tracking fields are empty, COSCO’s backend may be temporarily unavailable — try again in 30 minutes.

Scenario 2: “Discharged at T/S POD” posted with no “Loaded at T/S POL” for 7+ days. The container is likely sitting in the transshipment yard waiting for a connecting vessel. This is common at busy Ocean Alliance hubs. Contact COSCO’s local office or your booking agent for the confirmed feeder vessel and revised ETA.

Scenario 3: Trying to track an OOCL container on COSCO’s portal. Despite the parent-subsidiary relationship, OOLU containers will not resolve on COSCO’s portal. Use OOCL’s My OOCL Center (moc.digital.oocl.com) instead. The two systems are completely separate.

Scenario 4: API documentation is in Chinese and you cannot read it. The COP API documentation on GitHub is primarily in Chinese. Browser translation tools (Google Translate, DeepL) can help with basic navigation, but the legal agreements and technical specifications lose nuance in translation. If you are a non-Chinese developer, consider using a third-party visibility platform that has already built the COSCO integration rather than building directly against the COP API.

Scenario 5: Container rerouted due to Hormuz disruption. If your COSCO container was originally routed through the Middle East and tracking shows a gap or unexpected port change, the Hormuz-related booking suspension may have triggered a rerouting. Contact COSCO for the revised routing and updated ETA.

API and Integration Options

COSCO’s COP API is publicly available on GitHub at github.com/cop-cos/COP. The repository has 54 stars and is labeled “Trial operation” (试运行). SDKs are provided for Java, Python, and PHP. Authentication uses HMAC-SHA1, and the rate limits are strict: 1,000 calls per day and 30,000 per month.

Access requires a 15-day review process. You submit an application, COSCO reviews it, and access is granted if approved. This is slower than Maersk’s self-service signup but faster than MSC’s sales-rep-gated process — assuming you can navigate the application, which is primarily in Chinese.

The language barrier is the real obstacle. The API documentation, legal agreements, and terms of service are Chinese-only. The GitHub repository’s README has some English, but the detailed endpoint documentation, error codes, and authentication guides are in Chinese. For non-Chinese development teams, this represents a significant barrier that goes beyond technical integration difficulty.

The last commit to the COP repository was October 2024. The repository is not abandoned, but the update cadence is slow. If you are building against this API, be aware that it may not reflect COSCO’s latest internal capabilities, and there is no public changelog or release notes in English.

Operational Note: COSCO is the carrier where the gap between the carrier’s operational scale and its digital accessibility is widest. The world’s fourth-largest container shipping line offers a portal that blocks automated access, an API documented in Chinese with a 15-day approval process, no DCSA membership, and event labels that match no other carrier. For teams that ship on COSCO regularly, the most practical path is often a third-party visibility platform that has already built and maintained the COSCO integration. Building direct is possible but requires more investment than any other major carrier integration.