Think about the API end game

API’s are gaining ground in freight movement, but the concept is still in its infancy in many ways.    By one unscientific metric, it seems application programming interfaces (APIs) are certainly gaining traction in the freight industry.
   At two different recent industry conferences, APIs have been the subject of their own session, a sure sign the concept is gaining prominence in freight movement. But, comprehensive use of APIs in transportation and logistics – essentially a mechanism for systems to send data back and forth to one another – is still in its infancy in many ways.
   API proponents have clear advantages over electronic data interchange (EDI) and other system-to-system messaging formats common to logistics for several reasons: the instantaneous, two-way nature of information sent via APIs; the flexibility of information capable of being sent via APIs versus EDIs; and the ease with which APIs can be built relative to EDI integrations.
   But Ken Pehanick, president and chief executive officer of SaaS Transportation, a transportation management software provider, said earlier this week the development of APIs should be driven by a single factor.
   “Think about APIs in this way: who’s the end user,” he said at SMC³’s annual JumpStart conference in Atlanta. “There are so many developers with no practical knowledge. How do you program that code to make it useful? If you write a bad API – nothing will kill it quicker than a bad API, if the user can’t decipher the code. APIs are made so we can keep them away from programmers.”
   Pehanick was giving a TMS provider’s view of API proliferation in freight transportation. While he’s tremendously excited about the potential for APIs, he’s also realistic about the industry’s readiness for them. And not necessarily from a technological standpoint, but a mindset standpoint.
   “The goal of a TMS is to automate end-to-end,” he said. “(Freight) rating in the API world has some great advantages. There are so many unknown accessorials. It’s very difficult to manage.”
   APIs, by offering carriers and shippers real-time connectivity (often via a TMS), can make those accessorials known instantly.
   “But the downside on rating is accessorials aren’t consistent,” he said. “We looked at this and only six were constant from 100 carriers. One guy calls it ‘limited access’ delivery, another calls it ‘construction site’ delivery. How do you manage it in API world? That’s a challenge.”
   Pehanick said only 40 percent of carriers can do API tendering while only 5 percent do API invoicing. No options but EDI if you want to automate that process.
   That’s a key point of contention about APIs for those that use EDI – they’ve come to rely on EDI’s structure and standardization. APIs, by their nature, are generally not “standardized.” Flexibility is a selling point of APIs in other industries, because it gives programmers the freedom to shuttle data back and forth in unconstrained ways.
   But API providers are developing freight-specific API templates that can be used as in a more standardized way. Aside from SMC³, which is building out its API capability after mostly being seen as a trucking rate repository connected via EDI, freight- and logistics-specific API developer project44, and mutli-use API developer Mulesoft have made significant inroads into the industry.
   However, beyond those templated APIs that govern specific, established freight transactions or messages, API developers can build pipelines for data that EDI just can’t convey. First, certain message sets were never built in EDI, and second, the very nature of EDI means certain information (like images) can’t be transferred by that format.
   “EDI is easily repeatable once established,” Pehanick said. “It’s just hard to establish. APIs are all unique. Maybe set some standards in some areas. But it’s really an open book to do what you want.”
   He noted that TMS providers are largely ready for the change. They’ve been integrating with APIs since before they came on the radar screen of carriers and shipper supply chain departments. He said SaaS Transportation has 500 different APIs. Integrations like Google Maps and payment functions are connected via API, so developers are actually more familiar with API coding than with EDI.
   “Everybody’s gotta get on the bandwagon,” Pehanick said. “Everyone’s sharing data with everything, and that’s all proliferating because of APIs.”