CIO Insight: An ocean of possibilities for APIs

   In mid-July I had an interesting conversation over lunch with a very plugged-in logistics software executive about the relevance of application programming interfaces (APIs) for the ocean freight industry.
   I asked him a basic question: what’s preventing the ocean freight industry from using APIs instead of the de rigueur method of systems communication, electronic data interchange (EDI)? He started his response by emphasizing that his company could build APIs to connect its customers with ocean carriers yesterday. The technological capability is not the problem.
   “So what is the problem?” I pressed.
   Well, he said, the biggest problems are the liner carriers’ legacy systems, and their general disinterest in providing a platform for dynamic pricing.
   Keep in mind, this is his opinion, not necessarily a definitive picture. And also note that each carrier looks at this issue from a slightly different perspective. But given this person’s livelihood is building software, and that it would behoove him to understand what shippers, carriers and logistics companies need, I tend to believe he’s got his finger on the pulse of the situation.
   If carriers are a stumbling block to broader adoption of APIs, why is this the case? The answer isn’t so simple. For one, the long-established EDI lines of communication work. They may not be optimal, but they function, and shippers, carriers and forwarders have spent a lot of time, money and other resources building those connections and structuring processes around them. Frankly, carriers probably believe they have bigger problems than switching from one messaging format to another.
   The dynamic pricing issue is at the heart of this, though. Rate marketplaces, rate management systems for forwarders, and some forwarders themselves are developing tools using APIs to capture rates direct from carriers and deliver them to buyers of capacity. These connections, however, are instance-by-instance, and essentially require carriers and shippers (and usually an intermediary, whether a forwarder or software provider) to build those APIs one-by-one.
   APIs are easier to build than EDI integrations, but they still take time, so it’s not like waving a magic wand. What’s more, building these APIs requires the carrier to give up, once and for all, the idea that their rates are proprietary.
   And some carriers, according to the software executive I spoke with, literally wouldn’t be able to migrate the manifest data from a specific sailing into a dynamic rating environment (even if they wanted to) because that data is locked away in a legacy system and not accessible via APIs. That, he said, restricts their ability to price their slots dynamically (if they were so interested) or to allow forwarders to do so.
   Think about this for a moment. Airlines and stadiums can price their tickets dynamically because they know exactly what their inventory is at any given moment, and, using logarithms, juxtapose that against other variables like how popular a flight or concert might be. That information is delivered to marketplaces via web services APIs.
   Carriers can’t, or won’t, do that because they either don’t want to price their slots dynamically, or their existing systems prevent them from doing so.
   Let’s look at this another way. Let’s say airlines priced tickets for their most frequent fliers the way ocean carriers price slots for their biggest customers. So Sally Businesswoman would engage in discussions with airline X about rates for 2017. In September, Sally commits to flying at least 25 times during 2017 between Los Angeles and New York on the airline and asks for a blanket rate. The airline responds with a $400 rate if she flies at least 25 times during the year, with penalties assessed if she fails to fly 25 times on the route.
   Sally then individually requests a seat on each flight she wants direct with the carrier (or through a third party system) using a specific code only used for making such requests. The airline responds to her request using another specific code, telling her if space is available on that flight. If it is, the seat is booked and the $400 rate is billed once the travel is complete.
   No one would structure their travel this way, yet every year, shippers structure their freight capacity procurement exactly like this.
   I’m not sure what harm carriers see in providing forwarders and shippers more avenues to dynamic pricing. The existing structure yielded big rates in global trade boom times, but those days are gone. The current model of shielding rates could hardly drive rate levels any lower than a dynamic environment would.
   And perhaps the accountability of a dynamically priced environment might allow carriers to hold the line a little better. There would be no rumors of certain lines driving down prices if shippers, forwarders, and non-vessel-operating common carriers knew exactly what carrier was offering what rate.
   Let me be clear here – the shipping industry clinging dearly to EDI is a two-way street. I have heard next to nothing from shippers wanting to ditch EDI in favor of APIs as it relates to ocean freight procurement.
   So shippers need to be ready to dance too for this change to happen. They need to be willing to change the way they book, to think more dynamically about their own procurement cycles, and then push their carriers to build rating APIs (and upgrade backbone systems to allow those APIs). If the carriers can’t build the APIs themselves, they should turn to API hubs or ocean freight management software providers that could homogenize the data sets and build standardized APIs for the whole industry to leverage.
   The change to APIs is coming, and it’d be nice if for once the ocean freight industry could play a leading role in technology adoption, rather than a trailing one.