In-Transit Visibility Isn’t a Data Problem—It’s a Standardization Problem

Freight moves through more tracking systems today than at any point in the industry’s history. 

Carriers scan shipments at terminals. Transportation management systems log status changes. Shippers, brokers, and customers have portals, dashboards, tracking numbers, and automated notifications. 

And yet, once a less-than-truckload (LTL) shipment leaves the dock, one of the most common ways to find out what is happening is still a phone call. 

That contradiction points to the real problem. 

The LTL industry is not short on shipment data. It is short on a consistent way to define, exchange, and interpret that data across the carriers, shippers, brokers, and technology providers involved in moving the same freight. 

One carrier’s “In Transit” may not mean the same thing—or arrive in the same format—as another carrier’s. A shipper working with five LTL carriers can receive five different versions of the same basic shipment events. And when freight moves between an origin carrier and an interline partner, detailed visibility can become even harder to maintain. 

The result is an industry that generates enormous amounts of shipment information while still relying on people and technology teams to repeatedly translate it. 

This is not simply a tracking problem. 

It is a standardization problem. 

And it is the problem the National Motor Freight Traffic Association, Inc.’s® (NMFTA)® Digital Standards Development Council (DSDC) developed the LTL In-Transit Visibility API Standard to help address. 

The Industry Keeps Solving the Same Visibility Problem 

Consider what happens every time two organizations begin exchanging shipment visibility data. 

A carrier has its own internal milestone definitions, status codes, exception reasons, and data structure. A shipper, 3PL, TMS provider, or other technology platform has its own model. 

Before those systems can communicate effectively, somebody has to make them understand one another. 

That often means mapping one carrier’s terminology to another organization’s terminology, interpreting carrier-specific exception codes, building custom integrations, and maintaining that logic as systems change. 

Now multiply that process across a network of carriers and trading partners. 

The underlying business requirement is usually the same: tell me what is happening with my shipment. 

But the industry repeatedly builds new translation layers to answer that question. 

That fragmentation creates practical consequences across the LTL ecosystem. 

More manual status inquiries 

When systems cannot reliably exchange or interpret status data, people become the integration layer. 

A shipper or customer calls the carrier. Customer service looks up the shipment. Operations investigates an exception. An email or phone call communicates information that may already exist digitally somewhere in the network. 

That is time being spent manually reconciling information instead of resolving the exceptions that genuinely require human attention. 

Integration work that becomes harder to scale 

For carrier technology teams, every custom trading-partner integration can mean another mapping to build, test, monitor, and maintain. 

For TMS and visibility providers, onboarding another carrier can mean accommodating another variation of milestones, reason codes, and status structures. 

Growth in trading partners should not have to create a proportional increase in translation work. 

Different customers receive different visibility experiences 

A shipper may receive clear, structured updates from one carrier and far less usable information from another. 

The freight may be moving exactly as expected in both cases. But the customer experience can differ simply because the systems describing the movement use different terminology and data structures. 

Interline handoffs can create visibility gaps 

LTL freight frequently moves through complex networks, including interline relationships. 

When one carrier hands a shipment to another, the customer’s visibility should not effectively stop at the handoff. 

But without a consistent standard for communicating those events, maintaining continuity across the shipment journey becomes significantly more difficult. 

More Tracking Technology Alone Does Not Fix an Interoperability Problem 

It is tempting to think the solution is simply more technology. More sensors. More portals. More dashboards. More point-to-point integrations. Those technologies can all improve how shipment information is captured or displayed. But they do not necessarily solve the underlying problem. 

A carrier can have excellent internal shipment tracking and still be difficult for another organization’s system to integrate with if its data is defined differently from everyone else’s. 

Adding another system does not eliminate that translation problem. In some cases, it simply creates another source of data that needs to be mapped. 

The more scalable answer is not for every company to independently reinvent how common shipment events are communicated. 

It is for the industry to agree on a common structure. 

What Does an API Standard Actually Change? 

An API standard is not a software platform. 

It is an agreed-upon way of structuring and defining information so different systems can understand one another more consistently. 

Think about a common unit of measurement. 

Two companies do not need to negotiate what common terms mean every time they do business together. The shared definition already exists. 

Shipment visibility can work in a similar way. 

If “Picked-up,” “Departed Terminal,” “Interline,” “Out for Delivery,” and “Delivered” follow a shared structure, trading partners do not have to redefine those events every time they connect a new system. 

The same principle applies to delays and exceptions. 

A carrier can still maintain its own internal operational codes and systems. The standard simply provides a common framework for translating that information when it needs to move between organizations. 

For carrier IT teams, that can mean less unique integration logic for every relationship. 

For shippers and 3PLs, it can mean more consistent shipment information across a multi-carrier network. 

For TMS and technology providers, it creates the opportunity to build against a common model rather than repeatedly normalizing entirely different structures.  Lance Healy, CEO of FreightFacts and leader of the DSDC In-Transit Visibility effort, connects that standardization directly to the next wave of operational efficiency: “ says “Standards in accessorials, shipment status, and exception codes are, all foundational elements for better AI tools and reduced manual requirements from managing exceptions.” 

What Is the DSDC LTL In-Transit Visibility API Standard? 

The DSDC LTL In-Transit Visibility API Standard establishes a common framework for communicating shipment status from the time a carrier takes possession of freight through delivery. 

It was developed through NMFTA’s Digital Standards Development Council and Digital LTL Council to address areas of shipment visibility that have historically been handled differently across organizations. 

At a high level, the standard creates greater consistency in three important areas. 

1. A common language for shipment milestones 

The standard defines shared milestones for events such as: 

• Picked-up 
• Arrived at Terminal 
• Departed Terminal 
• In Transit 
• Interline 
• Out for Delivery 
• Delivered 

The goal is straightforward: when a milestone is exchanged between systems, the organizations on either side should have the same understanding of what it means. 

2. A more consistent way to communicate exceptions and changes 

Shipment visibility becomes especially important when freight does not move exactly as planned. 

The standard provides a framework for communicating delays, exceptions, and other shipment updates in a more consistent format. 

Carriers can continue using their own internal reason codes while mapping them into a common structure for trading partners. 

3. Better continuity through complex shipment movements 

The standard also addresses areas such as interline movements, where shipment information can become more difficult to follow as freight moves between carriers. 

A shared Interline milestone and consistent partner information help create a clearer picture of what is happening during those handoffs. 

The standard is intentionally a framework rather than a hosted visibility product. Organizations continue to control their own systems and implementation approach and can adopt the structure based on the capabilities they support today. 

Why Should Carriers Care About Standardization? 

For carriers, the value is not simply having another API. 

It is reducing the need to solve essentially the same visibility integration problem separately for every shipper, broker, or technology partner. 

Without a common structure, each new relationship may require another round of status mapping and custom integration work. 

With a common standard, organizations can align around the same foundational definitions. 

That creates several practical opportunities. 

Reduce unnecessary status inquiries 

More consistent digital updates can reduce the situations in which customers need to call simply to understand where a shipment is or what has happened to it. 

That allows customer service and operations teams to focus more attention on exceptions that actually require intervention. 

Make customer communication more consistent 

Customers should not need to learn a different shipment-status language for every carrier in their network. 

A common milestone structure makes it easier for shipment information to appear consistently across carrier systems, shipper platforms, and customer-facing tools. 

Scale connectivity more efficiently 

A carrier growing its digital relationships should not have to completely redesign how it communicates basic shipment events every time it connects with another organization. 

Likewise, a TMS or visibility provider connecting to additional carriers should not have to reinvent its shipment-status model for each integration. 

The more organizations that align around a shared structure, the more reusable those integrations can become. 

Improve visibility across interline movements 

Interline shipments are a normal part of LTL transportation. 

Customers should still be able to understand what is happening when freight moves from one carrier to another. 

More standardized handoff information can help reduce the ambiguity that currently surrounds some of these movements. 

The Bigger Opportunity: Interoperable Digital Freight 

The In-Transit Visibility API Standard is one part of a broader shift toward interoperable digital freight. 

For years, companies across transportation have invested heavily in their own systems. 

Those investments are not the problem. 

The challenge is what happens when hundreds or thousands of independently designed systems need to exchange information with one another. 

Digital standards create a common layer between independently designed systems. As Lance Healy, CEO of FreightFacts and leader of the DSDC In-Transit Visibility effort, said, “the work reflects broad industry input: These standards have been created with input and validation from all sectors of the LTL industry. Deep expertise in operations expertise came together to upgrade APIs into truly impactful changes that drive efficiency for carriers, shippers, and 3PLs.” The goal is not for every carrier, shipper, or technology provider to use identical software; it is for the systems they already use to exchange important freight information in a consistent way. 

As more organizations adopt shared definitions, the value of the standard increases across the network. 

A shipment status should ultimately mean the same thing whether it is being viewed by a carrier, a shipper, a 3PL, or the technology platform connecting them. 

Start by Looking at Your Current Visibility Model 

Organizations do not need to begin by completely redesigning their technology environment. 

A useful first step is simply understanding how much translation work already exists. 

Ask: 

How many integrations, mappings, manual processes, or customer-service interactions does it currently take to give customers a consistent view of shipment status across the carriers and trading partners you work with? 

For many organizations, that is where the case for standardization becomes much easier to see. 

The DSDC LTL In-Transit Visibility API Standard provides the common milestone definitions, shipment-status framework, and exception structure organizations can use to evaluate a more standardized approach. 

Review the In-Transit Visibility API Standard and compare its framework with how your organization exchanges shipment visibility data today. 

---

Key Takeaways 

1. LTL visibility is not simply a data-availability problem. The industry already generates significant shipment information; the challenge is exchanging and interpreting it consistently across organizations. 

2. A common standard reduces repeated translation work. Shared milestones and exception structures can help carriers, shippers, 3PLs, and technology providers avoid rebuilding the same integration logic for every relationship. 

3. Standardization does not require everyone to use the same technology. It creates a common framework that allows different systems to communicate more consistently. 

---

Frequently Asked Questions