This discussion has been going for years: who wins the battle of EDI vs API? On the one hand, EDI is considered to be legacy technology that is difficult to implement and maintain. Yet at the same time many enterprise-grade software systems have it as a key element of information communication. In fact EDI continues to play an integral role specifically in the supply chain oriented industries such as logistics, automotive and, of course, retail.
On the other hand, more modern software systems and web services rely on API connections. APIs are usually much more cost-effective compared to EDI solutions. In addition to that, they make a strong case for helping businesses meet the demands of the omnichannel age as well as be able to react quickly to the changing needs of the market. While some supply chain processes are less time-sensitive, for others such as quotes comparison or shipments management timely reaction is of the essence, and the event-based, synchronous communication enabled by API can do just that.
With APIs gaining traction as a reliable communication channel in the supply chain relationships between B2B partners, many business decision makers are wondering whether they should replace the older technology. To answer this question, however, it’s critical to know what the difference between EDI and API is and which processes are best supported by each. And maybe – just maybe – and doesn’t have to be EDI vs API in the first place.
Part Un: The specifics of EDI
To begin with, EDI (Electronic Data Interchange) stands for the electronic exchange of documents, and it was introduced in as early as 1970’s to make it possible to transfer data between two software systems rapidly and securely.
For example, if a manufacturer would issue a contract abstract for a new business partner, they would create this document first in their own software system (usually, either CRM or ERP), then turn it into an EDI document, and send it to the partner using a secure communication channel. The access is provided only to authorized users, while audit trails and audits ensure proper security control and regulatory compliance.
Examples of other documents typically sent through EDI are purchase orders, advanced shipping notices (ASN), material claims, or invoices (here you can find more EDI-related transaction sets). Many of them are even bi-directional by default and include mechanisms for e.g. proper contract administration and execution management in supply chain, or rebate management transactions in insurance.
In this sense, EDI offers a superb alternative to a paper-based documentation exchange – it is highly secure, fast and enables large amounts of data to be exchanged with a single transfer.
Being probably the oldest method for data exchange, EDI has “accumulated” over the years a substantial number of messaging standards, partially depending on the industry, partially on geography. One of the most common ones is UN/EDIFACT, a standard defined by the United Nations, but there is also e.g VDA (a standard widely used in the German automotive industry), or TRADACOMS (used in the retail industry particularly in the UK). The US and Asia rely on yet another common standard, ANSI X12.
However, this means that even though EDI is a generally accepted data exchange mechanism, each organization will probably have a very different EDI implementation and EDI-related set of criteria. As long as an organization operates within its own industry and its own country, this shouldn’t pose any challenges, but how about choosing the right EDI transaction sets to be transmitted to the business partners overseas? This is why establishing EDI connections can become very time-consuming and heavy on resources.
Part Deux: The specifics of API
Now let’s review APIs’ capabilities as well as their advantages and disadvantages, bearing in mind that the goal here is to establish a foundation for our EDI vs API comparison. The name Application Programming Interface pretty much speaks for itself: It is a set of protocols, routines and standards that enables software programs and web services to interact with each other efficiently and without users’ involvement.
Taking the same example as above, as soon as a new contract abstract is issued by a manufacturer, say, in the internal ERP system, the ERP’s API will push an update to the supply chain partner’s own internal system (for example, their CRM) and update the status of the deal with this contract. The main prerequisite for it here would be that the APIs of these two applications have already been integrated with each other.
The keyword in this process is “synchronous communication”. While EDI is essentially a file-based and batch communication method that uses asynchronous calls, API can handle both types of communication but proves to be particularly useful when it comes to real-time information exchange. This being said, however, it is not very suitable for the transmission of bulk data. In fact, one of the characteristics of a good API is being able to actually limit the amount of data received in a single response as well as the frequency of data requests.
The compliance and security aspects, on the other hand, can be less strong with APIs than with the EDI-based communication. Please don’t get me wrong – it doesn’t mean that APIs are less secure than EDI per se! But they require critical and thorough examination of the communication management with external B2B partners who might potentially get access to the company’s entire data through an API integration – and this examination needs to be done at the early stages of the API strategy development.
Another aspect that is often cited as a drawback of API-based B2B communication is the lack of standards in the same way they are presented in EDI. What this means is that there are little universally accepted specifications for common business transactions. APIs often have different nomenclature for common objects such as purchase order or contract, meaning that it usually requires a complex one-to-one mapping between the message formats of an organization and each of its trading partners.
What is the difference between EDI and API
The reality is that if a business has already been using EDI-based connections for B2B communication, this is unlikely to change. Partly because of the “never change a running system” adage and partly because it would be a highly intimidating job since EDI connections are typically deeply integrated with the core business systems.
In addition to that, there are APIs and then there are APIs. A poorly designed API might need over 50 operations in order to submit a single EDI purchase order over it. This being said, though, APIs are becoming increasingly popular among software companies and developers, particularly in the supply chain management. Young companies often prefer not to invest into the EDI technology to begin with and just use APIs instead.
To recap, both EDI and API are valid strategies for connecting applications and services. However, there are quite a few distinctions between them due to their historical origins and purposes. Before we move on in our EDI vs API comparison, let’s review some of the most important ones.
| EDI | API | |
| Messaging patterns: | Traditionally, asynchronous communication with acknowledgement messages such as MDN or FA | Synchronous calls for real-time data exchange as well as asynchronous calls for bulk operations |
| Transport protocols: | Numerous protocols including AS2, AS4, OFTP, FTP, HTTPS and more | The fundamental communication protocol for API calls is HTTP/S |
| Standards: | Well-established standards with detailed definitions and structure of business transactions | Compared to EDI, hardly any universally accepted specifications for common business transactions |
| Message formats: | UN/EDIFACT, TRADACOMS, ANSI X.12, VDA, UBL and others | XML (for SOAP), JSON (for REST), YAML are the three most common ones |
| Content error handling: | Due to asynchronous batch processing, this typically takes place in an application (for example, an ERP system) at the recipient’s end | Due to the synchronous approach, an error would normally stop the API call, which means that error handling will take place at the sender’s side |
| Handling data updates: | When a document’s content is updated, typically just flat information with a successive version of the same document is transmitted. This leaves it to the recipient to parse the information, compare the versions and update the database with the changes | Either the recipient’s API will actively poll for updates or an update push notification can be configured via a webhook, so that only the updated information is transmitted to the recipient automatically |
| Data size limitations: | No limitations; designed for transmission of batch, high-volume data | Deliberately poses limitations on the volume of data to be received or transmitted to “protect” the server |
| Onboarding support: | Thanks to the high level of standardization, new partners can be on-boarded fairly easily and quickly – but as long as they share the same EDI standard | For each new trading partner, a new one-to-one connection has to be built often from scratch, unless a company uses an enterprise integration platform for the overall integrations management |
Does API replace EDI anytime soon?
Well, if you have read the entire article up until this point (kudos to you!), then you’ll probably already know the answer. EDI is there and it’s not going to disappear anytime soon. It surely has its drawbacks, but so do APIs. In both cases, the onboarding of new partners can be cumbersome (even though for various reasons) and long, the integrations management – complex, and the maintenance – expensive, especially when there are code modifications and changes in the partners’ applications, systems and services.
And yet both technologies complement each other in all the right ways. With EDI typical technologies, there is, for example, no way to validate information or enrich datasets, which makes data quality a concern. While this is by no means a default feature in case of APIs either, it is easier to implement; especially, if a company has an integration middleware such as iPaaS in place. And we have already established that while EDI simplifies the transmission of large datasets, APIs are an excellent response to the fast-changing business environment, able to provide event-driven, real-time updates.
Considering this, it is to expect that there will be a growing demand for API connectivity capability. Due to their lightweight and real-time nature, APIs can bring considerably more visibility into supply chain management, enabling efficiency improvement, better product traceability, and higher quality control.
In this light, EDI and API should ideally be able to coexist in a symbiotic relationship. It’s less about EDI vs API, but rather a case for EDI and API. For example, we’ve experienced some of our customers using EDI for one type of messages, e.g. invoicing and then API for another type, e.g shipment status, where time-sensitivity may be critical. But of course, this is easier said than done, considering that the two technologies have a distinctly different history which dictates how they are built and how any communication between the two can be established.
How to bring EDI and API together?
So, how do you combine an older (EDI) and a more modern (API) technology? While there might be several viable approaches, the less expensive one would be implementing an integration management solution (typically, an enterprise integration platform as a service). This way, you can make EDI and API share data fairly easily and with less development overhead. The two main requirements such a tool must meet at the following.
We have already established above that EDI and API use quite different communication protocols; while EDI delivers information over e.g. AS1, FTP or AS3, APIs use a more fast-reacting HTTP protocol. In addition to that, EDI, being the legacy technology, often resides on-premises, whereas APIs are almost always hosted in the cloud. This means that the capability number #1 that you should be looking for is the ability of a platform to connect cloud to ground; in other terms, provide hybrid integration.
In addition to that, EDI uses data formats that are very different from API. This leads to the second important capability that an integration solution must possess: The ability to translate / transform various data formats, so that if your legacy ERP sends data e.g. in the EDIFACT format, it can be translated into JSON or XML for your recipient’s cloud-based system to “understand” it, and vice versa. Most iPaaS solutions provide dedicated, ready-to-use connectors for the purpose of e.g. EDIFACT integration or XML integration.
But before you start with your integration strategy, you might want to consider the following: Modern software applications hardly use EDI at all. So, if your company is planning a large migration away from the legacy tools as part of the digital innovation strategy, it might be unnecessary to invest into an iPaaS solution if it’s only for this purpose. Don’t get me wrong – as an iPaaS provider, we do cheer any company’s decision to implement one (especially, if it’s ours, wink), but I’m just saying that an investment like that requires thoughtful consideration and must be aligned with the entire business digital strategy.
In conclusion, though, let me just stress that there is no right answer to the questions like “EDI vs API: which is better? Which one should I stick to?” The reality is that companies will increasingly follow the symbiotic approach. APIs have a long track record as “magic doors” to modern web services and systems, whereas EDI has a long track record as a reliable communication method in supply chain management (and not only). The sooner companies adopt the strategy of “and” instead of “versus“, the faster they’ll be able to adapt to the ever changing digital environment.
