Is logistics finally ready for APIs?

Is logistics finally ready for APIs?

Speakers at the TPM 2019 Conference in Long Beach last week said they are seeing adoption of application programming interfaces (APIs) in shipping accelerate. Photo credit: Caught in the Moment Photography.

The proliferation of application programming interfaces (APIs) across a range of international logistics functions is an encouraging step toward the digitization of freight and signals the industry is ready to embrace more efficient means of system-to-system communication.

An API allows software from different enterprises to communicate in a more real-time, less rigid fashion than electronic data interchange (EDI), the most commonly used system-to-system standard in logistics. APIs are the de facto mechanism for such exchanges of information in the broader world of technology, but the shipping industry has been slow to adopt them. The main reason is that it requires time and resources to rip out established EDI connections or migrate away from email data transfer processes that are perceived as largely “getting the job done.”

In recent weeks, however, ocean carriers, third-party logistics providers (3PLs), and drayage representatives have all touted the benefits of investing in APIs in conversations with

The casual way APIs came up in these conversations was a sign in itself that the technology is gaining traction. For instance, multiple shipping lines have, unprompted, brought up the subject of exposing their APIs to customers, 3PLs, and software providers as opposed to funneling information via email, flat files, a web portal, or EDI.

Meanwhile, at the 2019 TPM Conference in Long Beach last week, Weston LaBar, CEO of the Harbor Trucking Association (HTA), said his drayage operator members are intent on building APIs between their transportation management systems (TMSs) and the systems used by marine terminal operators to better coordinate appointments and dual transactions — when a truck returns an empty container and then picks up a loaded container in a single trip to a single terminal.

In mid-February, freight forwarder SEKO Logistics, a longtime proponent of APIs, partnered with New York-based Easyship to integrate SEKO’s international freight services with Easyship’s platform for small e-commerce sellers. The connective tissue underlying this integration is APIs.

Fits and starts

These are only a few examples of the normalization of APIs in international logistics. Most of the software companies and digital-native logistics companies that have sprung up in the last five years have been quietly pushing for broader use of APIs, even as they encounter the realities that EDI and email are the preferred means for most shippers today.

That APIs are gaining traction is welcome news to those software providers on the vanguard, companies that have literally built their platforms around API integrations with the expectation that the industry they serve would eventually come around.

The concept has been around for decades, but the first use of APIs to connect logistics systems came in 2015, primarily pushed by Chicago-based visibility provider project44, which started out using APIs to connect less-than-truckload carriers to brokers and shippers. The company has since widened its reach to other modes, including ocean freight, with connections to 77 North American container terminals.

But adoption of APIs has been sporadic, particularly on the international side of the freight industry.

SEKO’s connection with Easyship is symbolic of how APIs underpin a new ecosystem of software around the movement of goods, driven in large part by the rise of e-commerce. Easyship’s customers are sellers of goods, ones that takes orders directly on their site or through an e-commerce marketplace.

It’s somewhat straightforward for such sellers to arrange for courier services to move their goods domestically, but when the orders need to go international, they struggle to provide a seamless experience for the freight legs or must use more expensive international parcel services.

The partnership, which covers Asia Pacific, North America, and Europe, is based around APIs connecting SEKO’s forwarding system with Easyship’s customer-facing platform. That platform allows the sellers to present customers with pricing options for their goods, including taxes, duties, and shipping costs.

“The consumer has all the power now,” said Brian Bourke, vice president of marketing at SEKO Logistics. “They have redefined transit times, lead times, and what it means to be transparent. This shift to APIs is consumer-led, because the velocity of e-commerce requires newer technologies.”

Bourke said SEKO has made a strategic decision to integrate more with other platforms that enhance its service offering to customers, integrations that are best facilitated through APIs. “It’s allowed us to scale. There’s no one platform that can solve every problem that retailers have.”

A more effective connection

It’s perhaps more surprising to see API traction in the drayage space, a freight transportation leg that’s long been at the bottom of the proverbial technology totem pole.

But LaBar said drayage providers are intent on connecting more effectively through their TMSs. “The biggest thing we want is API integrations,” he told “The three main [drayage] TMSs all have APIs or are building them.”

About a quarter of terminals in the ports of Los Angeles and Long Beach have direct API connections with drayage providers, with most in “pilot stage” at present, LaBar said. “But we’re moving toward that being the norm.”

HTA members believe more real-time API connections will foster more dual transactions — which LaBar said have plunged from 85 percent of all moves to as low as 20 percent in some terminals currently — thus freeing up drivers to do more moves daily.

“There’s no trucker shortage,” he said. “We have a capacity shortage. It’s a confined area, so we have to be more efficient. Implementing tech will allow us to increase dual transactions, drive up capacity, and release congestion.”

The proliferation of APIs comes as technology providers are building functional ecosystems for their customers, allowing shippers to interface with one system that pulls data or functionality from several others via APIs. That’s in lieu of a shipper buying a single system and expecting that single software provider to give them access to all the data or features they need.

This web of data via APIs is particularly apparent in the world of cargo visibility, where no one software company has access to all modes, or even all carriers within a mode.

“I can show people our portals, [the] outcomes, but the real thing is what comes before that, the part where we normalize the data,” said Todd Ericksrud, founder and CEO of the street-turn technology provider Matchback Systems. “It’s not the output. I don’t care where the output is delivered, whether it’s in someone else’s platform. Our goal has been to be the industry standard for street turns. But it doesn’t mean they all have to come into our platform.”

An ‘ecosystem game changer’

To be clear, the nature of APIs between software providers — i.e., those for which technology is the core business — can be different from those between a software company and a carrier. That is to say, not all APIs are created equal. Sources have told that while it’s promising ocean carriers have begun to open up APIs around schedules and rates, the quality of those APIs varies.

According to research published in February by the freight rate marketplace Freightos, only three carriers — Maersk Line, Mediterranean Shipping Co., and CMA CGM — currently provide APIs for real-time data around schedules, tariffs, booking requests and confirmation, documentation, tracking, and online payment. The research also used whether the APIs were widely published as a determining factor.

Freightos called APIs “an ecosystem game changer” in its report summarizing its findings, but it warned that “before APIs [or carrier websites] can deliver instant service, carriers must internally connect their booking, allocation, and pricing functions in real time.”

This opens up opportunities for systems integrations providers to connect software platforms with companies like carriers (across modes), 3PLs, and even shippers. For instance, Kontainers, which builds software-as-a-service (SaaS) front-end platforms for forwarders, non-vessel-operating common carriers (NVOs), and shipping lines, said March 4 it has begun using Youredi to provide data integrations between Kontainers’ products and its customers’ applications.

Kontainers has also pushed for the use of APIs, including dozens of APIs it has built to connect to external systems, but some of its customers aren’t there yet, so using Youredi’s integration platform lets it connect when APIs aren’t available. Youredi provides integration via whatever data formats might need to be connected, such as EDI or flat files.

Just this week, Mercado, a SaaS supply chain platform helping importers to connect with their global trading partners, said it has begun using another integration systems provider,, to “extract data from their existing systems and exchange data between all parties.” Mercado has taken a similar approach to Matchback and SEKO in cementing additive partnerships with adjacent software providers.

Contact Eric Johnson at and follow him on Twitter: @LogTechEric.



Eric Johnson, good article, thanks for sharing. It’s very important to seamlessly match together online (API, synchronous) and batch (EDI, asynchronous) systems. Youredi enables the customer and its partners to automate not just message integrations but complete end-to-end processes (e.g Ordering, Invoicing, etc.).

API's are 'just' the conveyance. The data feeding the conveyance is key, and so I remain skeptical that changing the conveyance isn't addressing the underlying problems of data quality.

The comment about data quality is right on the money. This is the same thing with Blockchain, which is merely a tool. None of these things address horrific data quality or even untruthful data entering the communication channel from the get go. Blockchain "verifies" what its told initially, and if if someone lies (to use an extreme example) when they add their piece to the puzzle, the lie is perpetuated along the chain. Even in more commonplace situations, a TMS, for example, is only as good as the data feeding it. If your material master is wrong, don't blame the TMS when it fails to plan the right transportation.