Everywhere we turn in our personal or professional life, we’re bombarded with the promise of more data. But that data isn’t valuable unless we have the right tools to do something about it. How do you bring together huge amounts of data in real time, understand what it means, and decide how to act on it?
APIs are a key part of the answer. APIs – or application programming interfaces – help systems communicate with each other and share data, even if they weren’t built by the same developer.
JP Wiggins, 3Gtms vice president of logistics, sat down with Logistics Management to clear up what APIs are, what they look like in action, their flexibility, and why we’re still in the Wild West when it comes to integrations and standards. You can read the full interview with Logistics Management here.
LM: What’s an API?
JP: 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 physically 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.
How does an API differ from EDI?
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.
What are some of the API-related challenges that logistics professionals need to consider?
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.
What do APIs look like in action?
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?).
Any advice for logistics managers as they make their choice between EDI and API?
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 its use? Probably not.