--- source_url: "https://shipmnts.com/blog/ocean-carrier-track-and-trace-apis-integration-guide?utm_source=openai" title: "Ocean Carrier Track-and-Trace APIs: Who Has Them, How to Connect" mirrored_at: 2026-08-06T15:40:07.563Z host: shipmnts.com cited_in_42a: true mirror_canonical: "https://index.42a.ai/shipmnts.com/blog/ocean-carrier-track-and-trace-apis-integration-guide__q__utm_source_openai" --- > **Original source:** https://shipmnts.com/blog/ocean-carrier-track-and-trace-apis-integration-guide?utm_source=openai Discover which ocean carriers offer track-and-trace APIs, how the DCSA standard is unifying carrier data, and what it takes for freight forwarders to integrate them. Every morning, an ops executive at a mid-sized NVOCC in Nhava Sheva opens six browser tabs before her coffee gets cold — Maersk, MSC, CMA CGM, Hapag-Lloyd, ONE, and COSCO — just to find out which of her 40-odd active containers moved overnight. Each portal shows status in a different format. One says "Discharged," another says "Available for pickup," a third just shows a date with no context. By the time she's cross-referenced all six against her Excel tracker, half her morning is gone, and a client has already called asking where their shipment is. This is the reality for most freight forwarders trying to offer real-time **shipment tracking and visibility** without a unified data feed. Ocean carrier track-and-trace APIs exist precisely to fix this — but knowing which carriers actually offer them, and how to wire them into your operation, is where most forwarders get stuck. * * * ## Why Manual Carrier Portal Checking Doesn't Scale The math is simple and brutal. If you're running 500 TEUs a month across five carriers, that's potentially hundreds of individual portal lookups a week. Add customer SLAs that demand proactive delay notifications, and manual checking becomes a full-time job for someone who should be closing quotes or chasing AR instead. Forwarders who still rely on daily portal logins typically discover container discharge or rollover events 12-24 hours after they happen — long after the window to rebook a connecting leg or warn the consignee has closed. An **ocean carrier track-and-trace API** pulls the same event data directly into your TMS, so the update reaches your ops desk and your customer's inbox within minutes of the carrier publishing it, not the next time someone remembers to check. * * * ## Which Ocean Carriers Actually Have Track-and-Trace APIs Not every carrier is at the same stage of digital maturity, and the API landscape is uneven. Some lines have invested heavily in public developer portals with self-serve sandbox access; others still expect you to negotiate EDI feeds through a account manager, or offer no programmatic access at all. Carrier API Availability Access Model DCSA Standard Adoption Maersk Public developer portal Self-serve API key + sandbox Yes MSC Public API portal Registration required Partial CMA CGM Public developer portal Self-serve API key Yes Hapag-Lloyd Public API portal Self-serve API key Yes ONE (Ocean Network Express) API available Registration + approval Yes COSCO Shipping Limited/regional EDI or account manager In progress Evergreen Limited EDI-based In progress HMM / Yang Ming / ZIM Emerging, inconsistent Mostly EDI, some API pilots In progress The bigger carriers front-loaded their API investment because it reduces their own customer-support load — every automated status check is one less call to their helpdesk. Smaller or regional lines, and many NVOCC-only carriers, still route data through traditional EDIFACT (IFTSTA, COPARN) messages, which work but require more integration effort than a clean REST API. * * * ## The DCSA Standard: Why It Matters More Than Any Single Carrier's API The Digital Container Shipping Association (DCSA) — a non-profit backed by Maersk, MSC, CMA CGM, Hapag-Lloyd, ONE, HMM, and others — has been pushing a common Track & Trace API specification since 2020, now in its third major version. As of 2024, carriers representing a majority of global containerized capacity have publicly committed to adopting DCSA's data model for event codes, timestamps, and shipment milestones. This matters because before DCSA, "gate out" from Maersk and "gate out" from Hapag-Lloyd could mean subtly different things, tagged with different field names, in different time zones, with different levels of granularity. A forwarder building a multi-carrier integration had to write a separate translation layer for every single line. DCSA standardizes the 30-odd shipment and transport events (vessel arrival, discharge, empty return, and so on) into one schema, so once you've built a parser for the standard, adding a new DCSA-compliant carrier is mostly a configuration change, not a new engineering project. ### What This Looks Like in Practice Consider a Dubai-based forwarder handling FCL bookings on both Maersk and CMA CGM. Before DCSA alignment, their dev team maintained two separate polling scripts with two separate status-mapping tables. After both carriers moved closer to the DCSA Track & Trace standard, the forwarder consolidated this into a single ingestion pipeline that normalizes events before they hit the ops dashboard — cutting integration maintenance time by roughly half, according to their internal engineering estimate. * * * ## Direct Carrier API vs. Third-Party Aggregator Once you know which carriers you need, the next decision is whether to integrate directly with each line or go through an aggregator that has already done that work. Factor Direct Carrier Integration Third-Party Aggregator Setup time Weeks per carrier Days for full coverage Ongoing maintenance You own every schema change Vendor absorbs carrier-side changes Cost Free API, but engineering-heavy Subscription fee, lower engineering cost Coverage of smaller carriers Limited to carriers you personally negotiate with Often bundled, including EDI-only lines Data control Full control over ingestion and mapping Dependent on vendor's normalization logic **Direct integration** makes sense if you're heavily concentrated on two or three major carriers and have engineering bandwidth to maintain the connections. **Aggregators** make more sense if your cargo spreads across a long tail of carriers, including ones without public APIs — you trade a subscription fee for not having to chase down EDI mappings for a carrier you use twice a year. * * * ## How to Actually Integrate a Carrier's Track-and-Trace API Whichever route you choose, the mechanics are broadly similar across carriers: - **Register and get sandbox access.** Most major carriers require you to register on their developer portal, agree to API terms, and receive a sandbox key before production access is granted — budget 1-2 weeks for approval on some lines. - **Normalize container and BL number formats.** Carriers are inconsistent about whether they expect ISO 6346 container numbers, booking numbers, or bill of lading numbers as query parameters — build a lookup layer that tries multiple identifiers. - **Map event codes to your internal statuses.** Even with DCSA alignment, you'll still need a translation table between carrier-reported milestones and the statuses your ops team and customers actually see. - **Choose polling vs. webhooks.** Some carriers only support polling (you query on a schedule), while DCSA-compliant APIs increasingly support webhook subscriptions that push events to you — webhooks cut latency and API call volume significantly. - **Handle rate limits and downtime gracefully.** Carrier APIs go down or throttle requests during peak season; your integration needs retry logic and a fallback to manual lookup so tracking doesn't silently go stale. This is exactly the kind of plumbing that a modern **freight forwarding software** platform is built to absorb, so your ops team sees one clean event feed regardless of which carrier moved the container, instead of rebuilding this integration layer in-house for every new carrier relationship. * * * ## Frequently Asked Questions ### Do all ocean carriers offer public track-and-trace APIs? No. Major carriers like Maersk, CMA CGM, and Hapag-Lloyd have self-serve developer portals with API keys and sandboxes. Others, including several regional and NVOCC-focused lines, still rely on EDI messaging or manual portal access, which means you either negotiate direct EDI feeds or use an aggregator that already covers them. ### What is the DCSA Track & Trace standard and why does it matter for integration? DCSA is an industry body that publishes a common API specification for container shipping events, adopted by most of the largest carriers. It matters because it lets you build one event-mapping layer instead of a custom one per carrier, significantly cutting the engineering effort of adding new carriers to your tracking feed. ### Should a small or mid-sized forwarder build direct carrier integrations or use a tracking aggregator? If your volume is concentrated with two or three major carriers and you have in-house engineering capacity, direct integration gives you more control at lower ongoing cost. If your cargo spreads across many carriers, including smaller lines without APIs, an aggregator or a platform with built-in multi-carrier tracking is usually faster to deploy and cheaper to maintain over time. If you'd rather not build and maintain carrier API integrations in-house, the Shipmnts platform handles multi-carrier track-and-trace natively, feeding real-time events straight into your operations and customer notifications. [Book a demo](https://shipmnts.com/demo) to see how it works with your specific carrier mix.