The EDI 315 is the ANSI X12 electronic data interchange transaction for ocean container status: carriers and terminals send 315 messages to customers and systems as events occur, each carrying a status code, date-time, location, and the container and reference numbers it concerns.
The 315 is the workhorse of pre-API tracking integration, and it still runs much of the industry’s plumbing: batch files of status lines flowing between carriers, terminals, and shippers’ TMS platforms. Status codes cover the familiar arc, vessel departure, discharge, gate-out, empty return, with carrier-specific flavouring.
Its limits are its age: batch latency rather than push immediacy, code lists that drift by sender, and no built-in planned-estimated-actual discipline. Modern DCSA-style APIs address those, but integrations live long, so both worlds coexist.
Whether a milestone arrived as an EDI 315 line or a JSON event, it should mean the same thing, and that translation is the aggregator’s job. TrackingMCP normalises statuses from EDI-era and API-era sources into one event model in tracking, so consumers of the API never inherit the dialect differences underneath.
The EDI 315 is the ANSI X12 electronic data interchange transaction for ocean container status: carriers and terminals send 315 messages to customers and systems as events occur, each carrying a status code, date-time, location, and the container and reference numbers it concerns.
No. It is legacy but load-bearing: many terminals and carriers still emit 315 feeds, and large shippers’ systems consume them. New builds favour APIs; existing pipes keep flowing.
A status code and its date-time and location, plus identifiers: container number, bill of lading or booking references, vessel and voyage. One message typically reports one event for one container.
Normalised tracking API →
DCSA alignment →
More in Tracking data & standards: DCSA Track & Trace · Browse all 106 terms →