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.
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.
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 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.
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.
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.
Whichever route you choose, the mechanics are broadly similar across carriers:
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.
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.
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.
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 to see how it works with your specific carrier mix.