Putting APIs to Work in the Logistics Environment

As the entire supply chain continues to go digital, the question is, how can a logistics professional bring together copious amounts of data in real-time, get a “control tower view” of that data, and then act on it? One viable answer can be found in the application programming interfaces (APIs) that enable fast and secure data exchange across software systems.

By creating a more streamlined approach to information sharing, APIs help systems communicate with one another—even when those systems weren’t built by the same developer. In this Insider Q&A, 3Gtms’ JP Wiggins describes the role of APIs in the logistics environment, shows how they’re being used, and gives insights into what’s ahead for APIs in supply chain.  

Insider Q&A

JP Wiggins — 3Gtms, Co-Founder & Vice President of Logistics

Q: What’s an API?

A: An API is a generic term for how two different systems communicate with each other. The earliest and oldest example that we’re all familiar with is EDI, which basically centers on phys ically passing files in predetermined formats back and forth. In most cases, EDI is the generic term used to identify the transaction set of data being passed. In transportation, the common sets are tender, status, freight bills, etc. 

The sets have existed since the early 1970s and were created and defined by standards committees that spelled out what was in the set and how to use it. The standards committee goes into detail on the exact fields in the set and how to pass the data. In North America, the most common standard is ASC X12 (or just X12).

These transactions sets provide a place to start. For example, we have hundreds of carriers that only publish their data via ASC X12 EDI. Let’s say we are hooking up to their system for status. We know they are using 214 status and the X12 provides a guild to start the field mapping process. When dealing with APIs, there are no such standards involved. Systems designers can do whatever they want. 

We do, however, still think in terms related to X12. For example, an X12 tender has carrier ID, equipment, ship-to location, etc. Generally, we find that if a carrier has an API for tender that they have pretty much the same fields in their API as exist in the EDI transaction set. If you think about it, we are passing the same data. What changes is the way we’re passing it. 

Q: How does an API differ from EDI?

A: In many ways, they do the same exact thing. But these days, an API implies real-time two-way communication compared to the old EDI method where the file is written and then sent and then read and responded to and sent back, which all took time. What’s different is that with JSON or the XML APIs, you can pass additional data sets that are not restricted to the EDI format.

For example, companies often like to get proof of delivery documents from their carriers, but there’s no EDI format to do that. At 3Gtms, we created an API that allows us to pass that document back and forth. This is just one example of how an API is more of a program that can be integrated with some back and forth, and a lot more flexibility. One downside to APIs is that they can be more difficult and take longer to map because there are no standards.

Yet in transportation we’re dealing with generally-known data, so this is a minor concern. Passing data with ERPs and finance systems is more of a concern as the X12 standards have generally never really worked well here, and because application custom APIs are more common.

Q: What realities are logistics managers facing in today’s digitalized environment?

A: The world is obviously going digital and transportation is no exception. Every person and party in the supply chain can provide some form of digital information. The challenge is how do you bring all of this intelligence together and make it into actionable data? The problem is that there are now so many different types of carriers, order management systems, warehouse management systems, third-party tracking environments, weather providers, map providers, mileage providers…the list goes on.

Q: What are some of the API-related challenges that logistics professionals need to consider?

A: We’re still in the wild west of APIs right now. Integrations between two companies aren’t static; they’re living, breathing, and changing. Everyone out there is creating APIs, but there is no standard on how you create your API. For example, what happens when you’re dealing with two different solutions that have two different systems created by two different entities? Or, what happens when one company upgrades its systems? Can it ensure that it didn’t break the upgrade?

And if the upgrade does break, who’s going to fix it? These are some valid issues that companies are grappling with right now. Basically, when you’re planning for an integration between two different companies, you want an integration that’s being maintained and supported. Don’t just plan on writing it once and forgetting about it. That’s a fatal mistake.

Q: How far have we come on the digital and API front?

A: We’ve reached the point where all parties in the supply chain are digital, at some level or another. Even the smallest mom-and-pop carrier out there right now uses smartphones. This creates significant opportunity for the logistics manager that wants to use data to better manage his or her supply chain. And, because every commercial party in that process is digital, everyone in the enterprise is saying, “I have an API for that!”

This can create a challenge because it means companies aren’t assessing the situation from a business-flow standpoint. We need the logic to know how to integrate these systems, and it’s not just about mapping fields from one API to the next. It’s about leveraging business logic to actually use the data, and that’s what’s come a long way in the last couple of decades.

Q: Do APIs usher in any security concerns?

A: A modern API shouldn’t create any security concerns, assuming it follows modern standards for encryption and authentication. Older APIs may have introduced some vulnerabilities, but a modern one shouldn’t. An often-overlooked item is throttling or limiting the service.

For example, a user of the service normally sends in 100 requests, but something changed, and they now are sending in one million instead. Was it a mistake or intentional? Should they be sending in that many? What impact does that sudden volume increase have on your existing service? Is your system robust enough to handle this and adapt appropriately? These are all questions that need to be addressed.

Q: What are the most important differences/benefits API has over EDI?

A: APIs gives additional options that didn’t exist with the EDI function. The advantage of an API is that it allows you to take advanced steps for which there is no EDI data set (e.g., the passing of documentation for proof of delivery). With an API, you can also manage some actual programming (i.e., callbacks).

You might ask it to, “Send me an update when the shipment changes.” And the system will give you a callback when there is a change. Generally, EDI is based on passing files back and forth—a process that become onerous when you’re managing hundreds of thousands of files.

Q: What do APIs look like in action?

A: In the TMS environment, we’ve created an integration with an order management system that reveals basic information like, “here’s the order that’s making the move.” We may also get integrations from the warehouse management system (WMS), telling us that an order has been picked and staged.

Finally, we may need to integrate to an accounting system to determine who to invoice for a certain project, and then who we have to pay for the move. There are also third parties involved, so in those cases we may use a rating service or get distances and maps from Google Maps (to show on the screen). These are just handful of the many different integrations that all build upon each other, and that’s the real advantage of APIs: getting everything together under one umbrella and then adding business logic to it (i.e., which carrier should I select? Which mode should I use? Which carrier should I tender the freight to? And, what should I do if the carrier rejects the tender?).

Q: How does that added level of business logic apply in the supply chain?

A: In a typical freight move right now, and with all the digital parties involved, you’re talking about anywhere from 50 to 100 different “touches” for just that single move. With so many different touches, companies want to automate as much of that process as possible.

They want systems to just automatically deal with it, so that route planners, transportation coordinators, and supply chain managers don’t have to deal with an average of 75 different touches for every load. Instead, they want statuses to come in automatically and for everything to run smoothly with as few touches as possible. That’s where business logic comes into the picture and helps reduce the amount of hands-on contact that logistics professionals have once an order leaves their warehouses.

Q: Any advice for logistics managers as they make their choice between EDI and API?

A: Make sure that your choice of software and technology is not limiting you from taking advantage of newer APIs where appropriate. For, example, there was no EDI transaction for a rate which can now be done by API. Compare that with status messages which have been around forever with EDI and it may still be fine to be handled that way. From our perspective as a TMS vendor, we sit in the middle of everything.

In fact, very few systems have to deal with as many different systems as a TMS does. We have to sit within the four walls of your company, talking to your internal systems. We also have to sit outside, talking to your vendors, customers, and trading partners. It’s just not something you can deal with manually in today’s day and age, so APIs have become a focal point for us and for most of our customers.

Remember that all communication protocols come with advantages and disadvantages. The person who is “selling” the solution will spin a narrative on why the way they’re doing it is best. Don’t concern yourself with how data is passed; focus on the business flow and business requirements.

For example, do you really care if a carrier is giving you status messages via JSON, X12 or XML? No, but what you do you care about is that the carrier is giving you a status message that includes the data you need and within the timeframe you need. In today’s world, pretty much all systems have ways to communicate, so don’t worry about the technical details of mapping and protocols.

Focus more on the business requirements. The mapping of data is the easy part; it’s the business logic and automation to process the data into action where you need to focus. Everybody can pass data, but can they automate it’s use? Probably not.

About 3Gtms 

Gtms is the fastest growing, Tier-1 transportation management system (TMS) provider. It is dedicated to helping mid to large shippers and logistics service providers gain a competitive advantage through technology. Whether you move $5 million or $5 billion in freight, its 3G-TM solution seamlessly manages the full transportation lifecycle, including transportation planning and optimization, execution and settlement, empowering customers to make better shipping decisions while meeting their service goals. 3Gtms is dedicated to delighting its customers and as a result, holds a 100 percent customer satisfaction rate that is unmatched in the industry. 

CONTACT US TO LEARN MORE

UNITED STATES

4 Armstrong Road, Suite 210 Shelton, CT 06484

203-567-4610

[email protected]

EUROPE

Dorpstraat 14a 5325 XG Well The Netherlands

+31 (0)73 599 7027

[email protected]

www.3gtms.com