Container Tracking APIs and DCSA Standards for Freight Forwarders

Container tracking data reaches a forwarder in four ways: directly from a carrier's API (increasingly shaped by the DCSA Track and Trace standard), through EDI messages, through a visibility platform that aggregates many carriers, or by scraping carrier websites. The DCSA standard gives carriers one event model and one API shape, which cuts the work of reading each carrier differently. It does not make the data complete or certain: tracking returns milestone events and estimated dates, and an ETA is a forecast that carriers revise. If you want the shipper-side basics first, read Container Tracking Explained. This guide is for the forwarder deciding how to get the data and what to do with it. Standards details below are as of November 2026.

What DCSA is and what its standards cover

The Digital Container Shipping Association (DCSA) is a neutral non-profit set up by ocean carriers to publish common data models and API definitions for container shipping. Its members page lists ten ocean carriers as members (MSC, Maersk, CMA CGM, Hapag-Lloyd, ONE, Evergreen, Yang Ming, HMM, ZIM and PIL), and says members develop standards jointly with DCSA. The published standards include Track and Trace, Booking, Commercial Schedules, Operational Vessel Schedules, Port Call, Bill of Lading, Arrival Notice and Verified Gross Mass.

The standards are published openly on the DCSA reference site under an Apache 2.0 licence. A standard describes a data model and an API; it does not oblige any carrier to give you access. Whether a given carrier exposes its DCSA-style API to you as a non-customer, a customer or a registered developer is set by that carrier, so check its own developer portal.

DCSA Track and Trace and its event model

Track and Trace organises visibility into events. DCSA's own page names five event types in the current model: shipment events (milestones in the shipment and documentation lifecycle), transport events (milestones across legs and modes, such as a vessel departing or arriving), equipment events (physical events involving a container, such as gate-in, gate-out, load and discharge), and, new in version 3, IoT events and reefer events.

• Version 2.2 is the line most carriers and integrators have built to. DCSA's own communications describe it as one of its most widely used and adopted standards, and DCSA's members page lists Track and Trace 2.2 against each of its ten carrier members as of November 2026. Version 2.2 added a subscription callback so a consumer can be pushed updates instead of polling.
• Version 3.0.0 was announced on 30 September 2026 (as reported by AJOT). It adds IoT events (such as geolocation, geofence crossings and door status) and reefer events (temperature, setpoint changes, power status and alarms), better handling of corrected or withdrawn events, and support for exchanging events through carriers, platforms and other intermediaries. DCSA's reference page says the full 3.0.0 release is available through member and partner access, and AJOT reports a public release planned for the second half of 2027. DCSA has published a migration guide for moving from 2.2.

Event codes and classifications (for example, separating a planned, an estimated and an actual event) are defined in the DCSA specification and its event naming convention. Integrator documentation commonly shows these as classifier values such as PLN, EST and ACT, with equipment event types like GTIN and GTOT for gate-in and gate-out. Treat any list you read in a vendor's documentation as a lead and check it against the current DCSA specification before building on it.

A common misconception: "DCSA-compliant" does not mean "every carrier gives me the same data". Carriers adopt the standard at different depths and on different timelines, and DCSA does not publish a coverage figure you can plan around. Expect differences in which events are sent, how fast, and what is available without a commercial relationship. The 3.0 transition also means a mixed-version period is likely.

Other DCSA standards a forwarder meets

These matter at a high level; you will meet them before you meet the event model.

• Commercial Schedules (reference site shows v1, current 1.0.3): published sailing schedules between ports, the data behind point-to-point schedule searches.
• Operational Vessel Schedules (v3, current 3.0.3): the vessel's operational schedule by port call, including estimated and actual times. Useful for spotting that a vessel is running late before cargo events show it.
• Booking (v2, current 2.0.5): a common structure for booking requests and confirmations, which matters for matching events to the right booking later.
• Bill of Lading: includes electronic bill of lading modules. See e-AWB and electronic bills of lading for forwarders for the document side.

Version numbers are those shown on the DCSA reference site in November 2026 and change as standards are updated.

Carrier APIs, EDI, aggregators and scraping compared

These are not exclusive. Many forwarders take EDI or APIs for their largest carriers, use a platform for the long tail, and keep manual lookups for exceptions.

What tracking actually returns

A tracking feed returns events, not a continuous position. Typical milestones are gate-out empty, gate-in full at the origin terminal, loaded on vessel, vessel departure, transshipment discharge and load, vessel arrival, discharge, gate-out full and empty return. Each has a time and a location, and the better feeds mark whether the time is planned, estimated or actual. See how a container terminal works for what these gate and yard moves mean physically.

Two points to keep straight. First, an ETA is an estimate and is revised, sometimes several times, as a vessel's schedule moves. Treat a single ETA as the current best guess, not a promise. Second, a missing event is not proof that nothing happened. It can mean the terminal did not report it, the carrier did not forward it, or it arrived late. For which milestones matter most to a customer, see shipment visibility milestones.

Data quality problems to plan for

• Event gaps. A container can go from loaded to arrived with no transshipment events. Do not alert on "no update for X hours" without allowing for normal sea legs.
• Duplicates and corrections. The same event can arrive from two sources or twice from one. Corrected or withdrawn events are a known issue, and version 3 of the DCSA model addresses them explicitly. Store the source and received time, and deduplicate on reference, event type, location and time.
• Timezones. Check whether each time is local to the location or UTC, and whether it carries an offset. Comparing a local gate-in time with a UTC vessel cut-off is a classic source of false late alerts.
• Reference mapping. Events attach to a container number, a booking number or a bill of lading number depending on the source. Your own job number needs a reliable link to each, and you need to handle one booking with several containers, split bills and container swaps.
• Lag. Updates may be near real time from one carrier and batched from another. Record when you received an event as well as when it happened.

Designing an exception-based workflow

Few forwarders can watch every container. The practical design is to track everything and alert only on exceptions, then work the exception list. Useful rules, with thresholds that are your own choice and should reflect your customers and lanes:

• Missed gate-in: no full gate-in event by a set time before the cargo cut-off or vessel ETD.
• Vessel rollover: the booking is moved to a later vessel, or the vessel's departure passes with no load event. See rolled cargo prevention.
• ETA change: arrival estimate moves by more than a set number of days compared with the last value you told the customer.
• Dwell and free time: discharged but not gated out, or gated out but empty not returned, as free time runs down. See managing detention and demurrage exposure.
• Stale feed: no event at all on an active booking for longer than the sea leg can explain, which prompts a manual check.

Give each alert an owner, a next action and a customer message template, and review false positives monthly so thresholds improve. The shipper side of this is in the freight exception management playbook.

What to ask a tracking vendor

• Which carriers, and which event types per carrier, do you cover for my trade lanes? Ask for it in writing and test with my own containers. Do not accept a single coverage percentage.
• How quickly does an event reach me after the carrier records it, and how do you handle corrections and duplicates?
• Do you pass through planned, estimated and actual times separately, and keep the history of ETA changes?
• What are the API limits, webhook options and uptime commitments?
• Who owns the data, can I export it and what happens to my history if I leave?
• How is pricing structured (per container, per booking, per carrier, a platform fee), and what counts as billable if a container is tracked for a long time or fails to match?
• What happens when a carrier changes or closes its interface?

Build or buy: a decision frame

Build direct integrations when a small number of carriers carry most of your volume, you have developers, and you want control of the data and the alert logic. Buy a platform when you ship on many carriers, need coverage fast and would rather pay for maintenance than do it. Many forwarders combine the two. Whatever you pick, keep your own copy of events against your job number, so a change of vendor does not erase your history. A tracking tool is also one piece of a wider system; freight forwarding software compared covers where it fits.

How to tell customers what a status means

Customers read "gate-in" and "discharged" differently from the way operations do. Use plain labels, show the time and say whether it is actual or estimated. Say "estimated arrival" instead of "arrives", and tell customers when the estimate has changed and why if you know. State plainly that terminal and carrier data can lag. If a status is unclear, say you are checking rather than guessing. For the general lookup steps customers use, point them to how to track an international shipment.

What to do next

1. List your top carriers by volume and check each one's developer portal for what tracking access it offers you and on what terms.
2. Pick three to five exception rules, set thresholds that suit your customers and test them on last month's shipments.
3. Map your job numbers to booking, bill of lading and container references so events land on the right file.
4. If you evaluate a vendor, run a trial on your own containers and score it on the questions above.

Looking for partners at a destination or a lane you do not cover? More than 29,300 logistics companies are searchable by country and service in the CargoLinked directory, and the public requests board lists freight that shippers have posted for forwarders to quote on directly.

This guide is general information, not legal, technical or commercial advice. Standards, versions and carrier access change; confirm current details with DCSA, each carrier's developer portal and your vendor before you build or sign anything.