TMS and AI systems need more than a carrier's current shipment status. They need a complete, consistently structured record of transportation events — such as pickup appointments, arrival and departure events, exceptions, delivery appointments, actual event times, and reasons. Enterprise shippers should define those requirements in a Transportation Event SOP, then use an integration control plane to measure carrier event coverage and assemble a Complete Transportation Event Record across EDI, APIs, webhooks, and other sources.
A carrier can support EDI and APIs and still fail to provide the transportation events a shipper requires through a single integration.
That distinction matters because enterprise transportation systems increasingly depend on detailed events to drive workflows, measure service, answer customer questions, and provide the foundation for analytics and AI. A connection that returns only PICKED_UP, IN_TRANSIT, and DELIVERED may be adequate for basic tracking but insufficient for a shipper that also needs pickup appointments, arrival at pickup, departure from pickup, delivery appointments, terminal events, exceptions, and precise event times.
X12's EDI 214 standard illustrates the breadth of traditional shipment-status information: the transaction reports shipment status using event types, date and times, locations, routes, identifiers, and conveyance information. Carrier APIs can expose similarly rich data, but the events may be divided across multiple API domains rather than returned through one tracking endpoint.[X12 source]
Visibility platforms may not be a one-stop shop for transportation event status. Visibility platforms deliver events that render well for human uses who can extrapolate context from the reported data. For example, Visibility platforms may miss events due to polling and typically require context, e.g. intransit may also mean the pickup event has been completed.
|
KEY TAKEAWAY |
Transportation event data is the structured record of operational events that occur during a shipment lifecycle, together with the context required to understand those events.
|
Requirement |
Example |
|
What happened? |
Arrived at pickup |
|
When did it happen? |
2026-09-08T09:42:00-04:00 |
|
Where did it happen? |
Pickup stop 1 |
|
What is the resulting state? |
At pickup |
|
Why did an exception occur? |
Facility closed |
|
Where did the data come from? |
Carrier EDI 214, API, webhook, or visibility platform |
This structure is different from a single summarized status such as IN_TRANSIT. A state describes what is currently true. An event describes what happened. A reason explains why. An appointment describes a planned commitment. Those concepts should remain distinct when downstream systems or AI agents are expected to make decisions.
|
DEFINITION |
There is no universal definition of a complete carrier status feed. The required event set depends on the shipper's business model, TMS workflows, customer commitments, transportation modes, service requirements, analytics, and AI use cases.
A Transportation Event SOP should define the events a shipper requires carriers to report and the data standard for each event. At minimum, it should address:
In 1Logtech's carrier-integration operating experience, these requirements are often discovered through human conversations during onboarding rather than delivered as a published standard at the beginning of the project. That makes requirements discovery part of every carrier implementation and can create design changes that delay project completions.
A published Transportation Event SOP changes the starting question from “Does this carrier support API?” to “Which interfaces satisfy our required transportation events?”
Carrier API capability is often distributed across functional endpoints. Estes, for example, publicly documents separate Pickup and Shipment Tracking APIs. Its Pickup API includes pickup management, pickup milestones and exceptions, while its Shipment Tracking API provides shipment journey milestones and delivery-oriented tracking information. Estes API source That architecture is not inherently a problem; in fact, it delivers value and context to pickup events. It also demonstrates why the integration design must be based on required events rather than a protocol label.
For a given carrier, complete coverage could require:
Pickup API + Shipment Tracking API + EDI 214 + webhook = required event coverage
The exact combination will vary by carrier and by the shipper’s SOP. Transportation Event Coverage measures whether the available interfaces collectively provide the events required by the shipper.
Once the SOP defines the requirement and carrier sources are identified, the integration layer has a larger job than message translation. It must:
The output is a Complete Transportation Event Record: the normalized chronological record of the events required by the shipper's Transportation Event SOP. For an enterprise TMS, that record can drive workflows consistently across carriers. For a data platform, it provides a more stable analytical dataset. For AI, it reduces the amount of carrier-specific interpretation the model must perform before taking action.
AI increases the need for structured transportation semantics. NIST's AI Risk Management Framework identifies data-quality issues as relevant to AI-system trustworthiness. NIST source In transportation operations, ambiguity can enter well before the AI model sees the data: a carrier may omit an event, expose it through another endpoint, use a proprietary code, or the visibility platform may combine an event with a shipment state or reason.
An AI agent asked whether a carrier missed pickup should not have to infer whether AT_STOP, IN_TRANSIT, or an appointment message means the truck actually arrived. The integration layer should provide explicit facts wherever possible. Not surprisingly, Operations teams demand the same consistency so that they don’t need to confirm directly with the carrier via check call or website. Trust in data quality is foundational to your Control Tower and your emerging AI use cases.
AI-ready transportation event data is complete enough for the use case, consistently normalized, explicitly timestamped and contextualized, source-attributed, and sufficiently deterministic for downstream systems to safely interpret without reconstructing each carrier's data model.
1. Define the Transportation Event SOP. Decide what events and supporting data the business requires.
2. Assess Transportation Event Coverage. Evaluate each carrier's EDI, APIs, webhooks, and other sources of visibility against the SOP.
3. Design for the required sources. Do not force API-only or EDI-only architecture. Let the business need, i.e. your SOP, drive the data source.
4. Normalize transportation semantics. Separate events, states, reasons, appointments, stop roles, timestamps, and tracking health.
5. Build the Complete Transportation Event Record. Deliver a consistent, normalized event history to the TMS, data platform, analytics, and AI.
Transportation integration should be measured by the operational data it produces, not solely by whether a carrier connection is technically live.
For enterprise shippers, the starting point is a published Transportation Event SOP. That standard makes it possible to measure coverage, identify gaps before testing, and design the right combination of EDI, APIs, webhooks, and other sources. The integration control plane can then normalize those inputs into a Complete Transportation Event Record that is usable by the TMS today and planned AI-driven transportation operations.
If your carrier onboarding process starts with protocol questions instead of event requirements, consider defining the Transportation Event SOP first. 1Logtech can help map required transportation events to carrier interfaces and identify coverage gaps before implementation. Contact us