Special Coverage: API enters fast lane

Unsure whether APIs will gain traction in transportation and logistics? It’s the de facto way consumer and business-to-business applications communicate with one another in most industries.

   About three years ago, the Obama administration outlined plans to open to the public the vast troves of data contained within the federal government.
   These “open data” rules contained one element that is particularly noteworthy to the transportation and logistics industries: a mandate that federal agencies establish application programming interfaces (APIs) so that software developers can get quicker and easier access to all that federal data.
   The move to more directly connect the computing world to the government isn’t the noteworthy part. It’s the fact that APIs have become so accepted as mechanisms that allow systems to communicate in real-time that even the federal government knows the deal.
   And that tipping point seems imminent for the transportation industry as well. Last year, American Shipper chronicled the potential of APIs as a replacement for the industry’s standard method of system integration – electronic data interchange (EDI).
   Since that point, there has been an almost constant dialogue in the technology world about the ubiquity and usefulness of APIs, especially a new breed of APIs that are more flexible than those developed in the past. And a key point in this development is the emergence of so-called API “middleware” providers, companies that act as connection hubs through the development of agile and robust integration infrastructure.
   These middleware providers essentially take on the burden of building the code that powers API integrations. That frees companies that might use those APIs – anyone from a less-than-truckload carrier to an e-commerce vendor – from having to build those connections themselves. It’s a sort of outsourced arrangement that lets companies focus on what they do best.
   A May article in the technology journal TechCrunch theorized that API middleware providers and ad-hoc developers were raising the level of APIs available in the market. 
   “Third-party APIs are often flat-out better,” the article said. “They work better and provide more flexibility than APIs that are built internally. Companies often underestimate the amount of work that goes into building and maintaining the functionality that they can now get as a third-party API. Finally, third-party API developers have more volume and access to a larger data set that creates network effects.
   “Developers realize that much of the functionality they need to build into an app is redundant to what many other companies are toiling over. They’ve learned not to expend precious resources on reinventing the wheel but instead to rely on APIs from the larger platforms, such as Salesforce, Amazon and, more recently, specialized developers.”
   The article said the shift to third-party APIs is only beginning, but that these middleware firms are “fundamentally changing the dynamics of how software is created and brought to market.”

Transportation Relevance. In the transportation industry, the most prominent of these API middleware providers is Chicago-based software-as-a-service company project44, which has predominantly been focused on connecting less-than-truckload carriers and shippers through their integration platform. project 44 is trying to break out of the mold of being classified as a pure middleware provider – it wants to be seen as enabling more efficient commerce through faster and cheaper systems communication.
   The company, which builds cloud-based APIs, recently said it has crossed the 1,000-API threshold in the transportation and logistics industry. For context, the public API repository ProgrammableWeb has around 15,000 APIs at present.
   It’s hard to find a direct competitor for what project44 is trying to do. There are rateware providers and transportation management software providers (like Freightview and 3PL systems) that connect via APIs, some purely via APIs. But project44’s model is to build the APIs alone.
   APIs, it should be noted, are certainly anything but confined to the freight industry. If you open an app on your smartphone, you are accessing information via an API. If you buy plane tickets on an aggregator website like Expedia, those rates are being dynamically provided via API. But API usage stretches far beyond these consumer applications. Business-to-business usage of APIs has existed for the last decade, but is growing now due to the aforementioned more flexible API structures.
   “APIs have been used as a mechanism for linking programs since the early days of software,” PwC said in a recent report on APIs, Consumerization of APIs: Scaling Integrations. “However, API creation and design have significantly changed. Early methods were proprietary and created interdependent coupling among pieces of code and systems. If one side of the coupling required a code change, the other side was affected. Over time, APIs evolved to reduce the interdependency of tightly coupled interfaces, generally lowering the complexity of integration.”
   Indeed, one of the primary selling points of APIs is the speed with which they can be implemented.
   “EDI connections can take weeks, even months to make,” said Abtin Hamidi, vice president of sales and co-founder at the technology-oriented freight brokerage Cargo Chief, and a veteran of fellow brokerages Echo Global Logistics and XPO Logistics. “There are real world examples that take 22 weeks. I’ve had experiences of being told an EDI connection would take 18 to 20 weeks and they can’t start for 10 weeks, and they charge you $15,000 for the integration.”
   That seemed unacceptable to Cargo Chief, a startup focused on using modern technology platforms to reach underserved sections of the brokerage market.
   “This is my favorite thing to talk about,” Hamidi said. “It’s a passionate issue for us. The No. 1 problem, the root of all evil, was an inability to communicate effectively. Our tech stack is designed for big data, to receive messages and data transmissions via API. The traditional brokerage and legacy business’ goal is to be secure and scalable. We needed to do these connections in a far different manner than existed today.”
   Cargo Chief is using project44 as an API integration hub, and Hamidi said an early ability to establish an integration with a carrier in 45 minutes  made an impression on one of its shipper customers accustomed to long EDI implementation lead times.
   “The customer was through the roof,” he said. “Just the cost and time involved in setting up that EDI connection.”

Starting Point. Much of project44’s initial business has centered round providing API connections that drive for real-time pricing and transit-time information. The LTL industry has generally counted on databases of stored tariff and transit-time information. Shippers plug that data into their transportation management systems (TMS) to inform routing optimization and carrier selection. The data could alternatively be plugged into a warehouse management system (WMS), or a company’s e-commerce platform or enterprise-resource-planning (ERP) system.
   But the information in those tariff databases is static. For instance, when an LTL carrier amends its tariff annually, say from Atlanta to Memphis, a rateware provider like SMC³ would pull those amendments into its repository. A shipper would then upload that updated tariff to its TMS.
   The problem is that this information is not dynamic and real-time. It’s based on information that could theoretically be up-to-date (if a tariff query was literally submitted right after the upload), but is likely weeks or months old. The problem, according to project44, is that the current system is based on long-established EDI communication structures, ones that are deeply embedded in the transportation and logistics industry. Those structures, while widely used, aren’t as efficient as APIs, and also don’t mesh well with the emerging demands on carriers, brokers, and their shipper customers, the company says.
   Other API proponents describe this rating procedure as having to mirror the data in a TMS, rather than pulling real-time rate information directly from the carrier.
   SMC³, which says it has been developing its own APIs for the last decade, has argued that EDI is a format that binds transportation carriers together in a standardized way that APIs can’t.
   But project44 co-founder and chief executive officer Jett McCandless disputes the notion that API is a constraint.
   “We’ve standardized the data that’s transmitted to the TMS,” he said in an interview with American Shipper. “We take this dynamic conversation and standardize it into a message that perfectly fits their system. EDI requires long and expensive lead integrations that add little value once complete. It’s a rigid format that makes companies shoehorn their different data in. EDI is the only standard that’s not a standard.”

    McCandless, whose company processes roughly 2.1 million transactions a day through its APIs, gave an example of the way the transportation industry has made EDI work for uses it was never intended.
   “EDI 204 (a message denoting load tender) says ‘don’t use it for LTL,’ but everybody uses it for LTL,” he said.
   Much of the discussion around the suitability of APIs to the transportation industry has focused on whether carriers, shippers, and 3PLs require standardized formats for information exchange. Those skeptical of the potential of APIs to transform communications between systems say that shippers and carriers have too much invested in their current processes for a radical change.
   Some say the change is coming, but slowly, and that the two communications formats will exist side-by-side for the foreseeable future.
   “EDI is currently entrenched in parts of the industry, and this type of messaging is certainly not dying out,” Danny Slaton, chief operating officer and executive vice president at SMC³, wrote in a January commentary to American Shipper. “To switch to API, shippers and receivers who have used EDI for decades would have to make a large investment in time and money, while also sacrificing the level of detail and global services EDI currently provides. While some in the industry are painting messaging as an ‘either/or’ case (much like the less-than-truckload debate over density and classification rates), at SMC³, we see the two types of messaging co-existing for some time.”
   In a May interview, SMC³ suggested to American Shipper that APIs are best suited for smaller organizations and that those with robust, “industrial” information needs are likely to continue to use EDI.

New Era For APIs. McCandless said SMC³ portrays an inaccurate picture of where API development, capability, and usage is today. He noted that large 3PLs are already using APIs, and that, more broadly, APIs power much of how multi-billion-dollar companies like Google, Uber, Salesforce, and Facebook (not to mention around 80 percent of Fortune 500 companies) deliver their functions to users. Those companies rely heavily on the robustness of APIs to transmit huge amounts of data, he said, so it stands to reason that transportation companies with similarly large data sets could use APIs.
   Meanwhile, project44 has its sights set on wider uses of its API infrastructure than merely LTL transit-time and pricing data – basically anywhere that static information can be replaced with dynamic information.
   “There are an infinite amount of possibilities when you talk about APIs,” he said.
   An API between a carrier and shipper functions like a phone call: information is passed back and forth, sometimes simultaneously, but it requires both sides to be connected at the same time. EDI, on the other hand, is like a mail delivery or fax. The information contained in an EDI message, for example, can be delivered at any point, and doesn’t require the receiver to be connected at the time of transfer. But the sender has limited ways of knowing if the message was received, much less if it was accurate. Nor does it know if the receiver needs more information. 
   project44’s Chief Technology Officer Wally Ibrahim, in a Q&A with eyefortransport in early 2016, put it this way: “EDI’s technical shortfalls increase the overall cost of freight transportation, lead to greater inefficiencies, and limit end-to-end visibility. With EDI, shippers and 3PLs are spending more time on administrative tasks and less time on revenue generating activities. Furthermore, they have no access to the big data required to make dynamic business decisions. Using EDI is like asking a stockbroker to make trades today with yesterday’s paper.”
   Hamidi used a similar metaphor to describe the way his company functions and how incongruous EDI is to that manner of operating.
   “Our business looks like a Wall Street trading floor more than anything else,” he said. “We get prices from carriers for a particular transaction and a carrier who has a slow connection loses that load. With so many integrations and connections, you can see the problems that slow integrations create. Carriers with slow connections lose a significant amount of business from us because we can jeopardize our customer relationship if we don’t have a quick connection with the carrier that’s optimal for that lane.”

Wither EDI? But is EDI really so bad? A white paper released in March by the University of Tennessee said the problem is that EDI was built for a different era. The technology was developed just after World War II and refined in the 1960s and 1970s. All of that development happened, of course, prior to the advent of the Internet.
   “In its day, EDI was a major advancement over postal mail and fax,” authors of the white paper, The Road to Profitability is a Web Service Connection, wrote. “Transitioning from a paper-based exchange of business documents to a computer-to-computer interchange reduced costs, increased processing speed for many activities in the supply chain, and reduced the likelihood of errors. Many thought EDI was the ultimate technology solution for improving the efficiency and effectiveness of information flow.”
   But the white paper notes the rigid format as a constraint in modern, Internet-enabled transportation processes.
   “EDI exchanges require a standard format in order for Company A’s computers to be able to read and understand the data from Company B,” the report said. “Without a standard format specifying what the information is and in what format (e.g., integer, decimal, mm/dd/yyyy), it would be like an English-speaking only person trying to comprehend someone speaking in Mandarin Chinese. Even though EDI adopted several standards that are in use today, each standard has many different versions. For any two supply chain partners to exchange data, documents or information via EDI, they must agree on the specific standard and version.”
   Those who hold that EDI is too entrenched in transportation to be left behind note that these rigid formats help in a way, because they define operating processes and force companies to adhere to those processes, even if they aren’t necessary optimal.
   But the white paper’s authors said that thinking is outdated.
   “Suppose a shipper has a shipment originating in Chicago and headed to Mobile,” they wrote. “The shipper tenders the shipment to its strategic (or core) LTL carriers – using outdated rates established seven months earlier at the start of the year. Now the waiting begins because the EDI is batched with several others, and then sent to the first carrier specified.
   “Once received by the carrier, it is again put on hold until the carrier downloads their batch of EDI transmissions, ranging anywhere from every 15 minutes to 2 hours. A pick-up is scheduled and confirmed using EDI, but these notifications are also batched with others, adding more time to the overall process. Would any of us wait this long or tolerate this process if you were making a hotel reservation or purchasing an airline ticket?”

APIs Not All The Same. This is a good point to highlight that not all APIs are the same. Hamidi, who’s been involved in several startups, said he’s seen his share of poorly built APIs. The PwC report called the relatively recent development of representational state transfer (REST) APIs a major advance in the quality of these communications pipelines over previous versions that used an earlier structure called Simple Object Access Protocol (SOAP). Media reports charting the rise of APIs note the number of public APIs provided by organizations like ProgrammableWeb. In other industries, TechCrunch cited a number of third-party API middleware firms like “Stripe and Plaid for payment connectivity, Twilio for telephone and messaging applications, Factual for location-based data and Algolia for site search.”
   The next trick in a transportation context is applying APIs beyond the initial LTL applications into areas that affect shippers’ and logistics companies’ supply chain management processes.
   project44 told American Shipper it is working with a major North American retailer to develop better inventory management capability on both the e-commerce and brick-and-mortar sides of its business.
   On the e-commerce side, McCandless said retailers struggle to get real-time transit-time information, affecting their ability to mitigate shopping cart abandonment (where shoppers put something in their e-carts but don’t actually buy the items). The problem manifests itself, in particular, with big-ticket items.
   A customer may put an item, such as a piece of furniture, in his or her online shopping cart, but then be put off by the uncertainty surrounding the delivery window on that item. That’s because the technologies that power online shopping carts aren’t well-connected with real-time freight rates and transit times via API.
   If that customer ordered a small package, there’d be more certainty on the delivery window, because small package delivery companies like UPS and FedEx have systems that link delivery milestones to customer-facing visibility systems via API. Those linkages aren’t common in the freight world.
   The issue, McCandless said, is that online shoppers don’t know, nor do they care about, the differences between small package and freight. APIs allow this retailer to make freight items bought online ship like small package, he said.
   “We’ve set up transit-time APIs from whatever origin zip code based on the items in the shopping cart,” McCandless said. “That lets the retailer decide whether it’s best to use a drop-ship vendor, fulfill out of their own inventory, ship out of the store, and in a nanosecond, it gives an accurate transit time.”
   The end result is a reduction in shopping cart abandonment, providing more revenue to the retailer and better customer service to the shopper.
   Another e-commerce issue is that e-shopping carts don’t provide shipping options based on the cost to provide a particular level of service.
   “Freight items usually have flat shipping costs because e-shopping carts don’t work the same way as TMSs do,” McCandless said. “There are base rates loaded into a TMS and it’s optimized based on the best routing. E-shopping uses average shipping costs for a couch. With a rating API, you can tie it into the inventory management system to give you shipping options. So it would be $55 to have it in three days, or $100 tomorrow. Now it will be profitable for retailer and at least cover the cost of the freight.
   “Retailers who want to compete with Amazon, this is a way to compete with Amazon,” he added.

Inventory Help For Retailers. The retailer’s brick-and-mortar challenges are different, and revolve around avoiding stock-outs, where a customer goes to a store to locate a particular product and instead finds the shelf empty. To ensure a smaller percentage of customers experience stock-outs, major retailers are putting pressure on their vendors to meet tighter delivery windows to warehouses.
   That puts the onus on both retailers and suppliers to have better, more dynamic information.
   “Retailers have to move based on what’s happening with seasons and trends,” McCandless said. “The difference is, people want things so fast now. If it’s 85 degrees in Chicago in March, people want a grill. They want products on shelves, or deliveries to their homes with accurate transit times.”
   That pressure on suppliers can mean penalties from retailers, not just the threat of lost business. The trouble, McCandless said, is that it’s hard to trace why a delivery might be late if visibility systems aren’t supported by real-time information.
   For instance, if a supplier is late delivering a shipment to a retailer’s warehouse, is it the fault of the supplier, the carrier, or the retailer? Maybe the supplier is using the retailer’s carrier of choice, and that carrier sat on the shipment for two days. Maybe the supplier tried to get an arrival appointment at the warehouse, but couldn’t. Maybe it took the retailer three days to process the shipment. Or maybe the supplier was at fault.
   McCandless argues that current EDI message sets don’t allow the parties in such a transaction to delineate where the fault lies, in part because a retailer’s backbone record locator (such as a purchase order) doesn’t neatly fit into EDI formats. But technologies like geo-fencing (which uses GPS locations to track whether a truck has crossed into a pre-defined area), coupled with APIs, allow visibility to be real-time.
   And the next step is using that real-time information to power analytics, where users of APIs can leverage more accurate real-time information into supply chain decision-making. 
   “Say there’s a huge amount of people with the common cold in L.A.,” McCandless said. “That means there’s going to be a shortage of drivers, plus we see that carriers are taking two days. We can proactively notify you there may be a problem meeting your ‘must-arrive-by’ date. If you can get ahead of this stuff, then you’re better off than the competition, and you sell product—that’s what everybody wants.”

Early Stages. Whether talking about API usage in the transportation industry or in broader supply chain management applications, the reality is that acceptance is still in its early stages. That may be part of the normal technology adoption curve, with early adopters and innovators (according to Everett Rogers’ theory of innovation diffusion) eventually leading to a broader majority of users. McCandless compared the use of APIs versus EDI to physical catalogs versus e-commerce adoption.
   As an example of where much of the trucking industry is on the issue of connectivity, last August at the Baltimore Crab Feast, a sun-soaked gathering of freight forwarders, carriers, customs brokers, and transportation providers, American Shipper spoke with a person in charge of business development at a midsized Canada-based trucking company.
   He described how it was like pulling teeth to convince the executive-level of his company to invest in any sort of technology. To them, he said, just getting to the point of using EDI seemed like an unattainable Holy Grail, never mind APIs.
   And bear in mind, from conversations American Shipper has had with a number of transportation and logistics software providers, it has been far easier for API proponents to convince the carrier community of the benefits of APIs than the shippers.
   Most conversations with those software providers go something like this: “We can easily set up the APIs, but most shippers are happy with EDI.”
   That thinking is rooted in two cost areas—the investment already made in establishing EDI connections, and the business processes in place that rely on those EDI connections. Switching from EDIs to APIs does in fact change the way a company functions, and many companies are satisfied with their current business processes.
   API proponents would argue those companies often don’t know how much better they could function if they knew there was a better way. Indeed, McCandless said he typically has the most success with potential customers who are new to the possibilities of APIs by showing them a single-use case.
   “I talk to them about how APIs are open, but most people tend to need their immediate problem solved,” he said. “I can present a nirvana where everything is happening with APIs, but it’s more realistic for me to take them from A to B to C. I can’t always take them from A to F. I have to take them on a path.”