EDIs and APIs are, in a sense, two sides of the same coin — information needs to flow from one entity to the other, in a specified format, in a useful way. However, the details of the specific technologies expose a good deal more complexity, and the differences between them might not be readily apparent.

So what specifically is an EDI? And for that matter, what is an API? Let’s take a look at these questions. Below, we’ll dive into these two technologies, discuss their benefits and drawbacks, and examine their core use cases.

What is EDI?

An EDI, or Electronic Data Interchange, is a standard format for the interchange of electronic documents. In essence, an EDI is a standardized method to send large amounts of data over a secure network in an understandable and parseable format. EDI is most commonly used in the shipping and logistics industry, and has a storied history in logistics management. It should be noted that EDI refers both to the concepts and standards commonly referred to as EDI as well as an EDI data entity itself — accordingly, we will be referring to it here both as a noun and a standard.

EDI data often looks quite confusing to those unfamiliar with the various standards, but their utility is easy to see once a basic structure is understood. Let’s look at an example ANSI Standard EDI purchase order, which can be found on the website EDIBasics.com:

ST*850*1001
BEG*00*SA*4768*65*20120930
N1*SO*XYZ Company
N3*123 Main Street
N4*Fairview*CA*94168
PO1*1*100*EA*27.65**VN*331896-42
CTT*1*100
SE*8*1001

In this set of data, each line is preceded by a segment ID. ST indicates the start of a transaction set, BEG indicates the beginning of the purchase order, and so forth. Each line references a particular element of the segment itself. This order would, when rendered into text, read as follows:

Start transaction set based upon the numerical code
Begin purchase order based upon the numerical code
The first name segment is XYZ Company
The address is 123 Main Street
The city is Fairview, CA, 94168
The line item detail can be calculated with these numbers - in this case, 27.65 per unit, with 100 orders of the product ID 331896-42
Now summarize the purchase order data
And with SE, the purchase order data set closes

This purchase order would be more regularly summarized as an entire page of order data, with tables loaded with columns and rows to differentiate what is being purchased and for how much. A PDF sized to transmit this data would be quite larger than a simple string of text. Now imagine this transaction over several million orders, and you can begin to understand the gravity of a properly integrated and supported EDI.

The History of EDI

The concepts behind the EDI standard are rooted in the logistics innovations of the 1900s, with many historians crediting the Berlin Airlift as a prime situation that exposed the need for more robust logistics systems. With the world becoming more interconnected and the amount of logistics material being moved exponentially increasing, the need for a standardized format for the transmission of business data only became more apparent. Operations such as the Berlin Airlift saw vast amounts of data being transmitted over teletype modems designed for strikingly smaller use cases. A lack of a standard transfer format was quickly discovered to be a core weakness in the data transfer process.

After the success of the Berlin Airlift, US Army Master Sgt. Edward A. Guilbert, one of the logistics officers who helped develop the US Army standard manifest system, which enabled the airlift to succeed, took his experience into the private sector. In the early 1960s, Guilbert developed an early EDI while working at Du Pont Co. to facilitate cargo management with their principal carrier, Chemical Lehman Tank Lines.

In 1968, multiple corporations, each using their own manifest systems, formed the Transportation Data Coordinating Committee (TDCC), and in 1975, this organization created the first EDI standard specifications for the private sector. While the initial cost of utilizing an EDI resulted in higher utilization rates in larger companies, over the next few decades, innovations in computing, network infrastructure, and the relaxing of internet regulations for businesses would result in EDIs seeing widespread adoption. EDIs are widely used today to facilitate the transfer of business documents and information across organizations utilizing a variety of standards, including:

• UN/EDIFACT International Standard
• ANSI ASC X12 North American Standard
• HIPAA EDI Standards for US health data

There are many, many more. EDI standards often differ depending on the type of business where the EDI lives, as each industry will have its own regulations, requirements, mandates, and standards for security and safety.

Benefits

EDIs have several benefits. First and foremost, EDIs are built for logistics. The value of having a purpose-built solution can’t be understated — while APIs can certainly fill the function that an EDI might fill, APIs are a more generalist solution. EDIs, on the other hand, are specifically designed to deal with logistics and information transfer.

This specific focus also results in an overall boost to security. EDIs are typically designed to facilitate data transfer and meet the regulations around data transfer. For example, when building an API for healthcare data, a lot needs to be done to ensure that it is HIPAA compliant if the business is in the United States. By adopting a standard EDI designed for HIPAA communications, this issue can be sidestepped. EDIs are also intended to open secure connections between a limited set of parties, and this is typically limited to just two. Since this is a much more secure communication channel than something happening over the internet on a system that is not explicitly designed for this function, it could be a more secure connection format.

It should also be said that EDIs are, in many industries, absolutely standardized and widespread. In these situations, the idea of everyone using an EDI is a considerable value proposition — it’s easier to use the same thing that everyone is using, and support and iteration will be less costly. There are also more users on the system who have stress-tested it and iterated over the years to provide a better experience. In essence, EDI is tried and tested.

Drawbacks

EDIs are not perfect, however. There are a few significant drawbacks that exist in specific circumstances. The biggest of these drawbacks is that the “EDI Standard” is a collection of standards specific to each partner. A healthcare EDI, for example, may be different from an aviation EDI. At first blush, that seems absolutely sensible — after all, there are different standards because the data is very different. The modern economy has seen a recent boom in combinatory endeavors however, with drone-based last-mile delivery, healthcare provisioned through mail-order services and online health portals, and other new technologies seeing massive growth. In light of this, classic EDIs can, in some cases, create barriers between different organizations that want to share data in a parseable and transferable way.

Speaking of data transfer, there is also the fact that, in almost every circumstance, EDIs are between two parties. Both parties must agree to the connection, have compatible standards, use compatible software and transmission methods, and so forth. This results in a connection that is only useful for that particular communication instance, meaning that every new connection requires the creation of a new channel and re-implementing base functionality.

EDIs can also be expensive. Even though the technology has been around for decades, there is still a high cost to implement these systems, train operators, and develop the underlying infrastructure. While this is not necessarily a deal-breaker, as the infrastructure often leads to additional revenue opportunities and functions, this is harder to justify against newer technologies such as APIs, where the cost to develop and iterate is much lower.

What is an API?

APIs, or Application Programming Interfaces, are interfaces that clients can call to exchange data or functionality. When a machine wants to get data, transform something, or even just read the state of something, there needs to be a mechanism for this transit. There must be an agreed-upon language for the request and some sort of expected format to actually read the results. This is true for both external resources — such as checking the weather of your vacation location the week before — as well as internal resources — such as when a graphics card takes machine instructions and renders an image on-screen. APIs serve this function, connecting resources together with those who wish to consume said resources.

It should be noted that APIs are core to the function of the modern internet. APIs have iterated alongside the world wide web, leveraging the HTTP standards and adjacent systems like JSON to create unique, engaging content. When we discuss APIs in this context, we use the term API for shorthand, but we’re really talking about web APIs. Web APIs take the same concept that regular system APIs function upon — the conversion of a request and response into a standard format — and utilize the internet as the transit layer.

One succinct way to state what an API does can be found on this Nordic APIs page:

“APIs have been described as the glue holding the Internet together. They are woven into the fabric of most things end users do on their devices. Ever wonder how you can play Spotify from within an Uber? APIs enable two otherwise distanced entities to talk to each other in a more standardized format.
Things like using a social account to authenticate on a website, having the weather on your phone, being able to access Google maps from a separate application, or triggering Internet of Things devices — they all rely on APIs to function.”

This conversation becomes somewhat complicated because APIs can function similarly to EDIs. Using an agreed-upon standard, such as a HIPAA-compliant security layer and document format, an API can be an API with functions that almost precisely mirror an EDI. So what is the core value argument for APIs?

Benefits

APIs are flexible by their very design. An API, if adequately developed, should be extensible, scalable, and friendly to iteration. This is a huge benefit of API adoption — the ability to rapidly iterate for business purposes unlocks a wide range of potential revenue and operational growth strategies. Additionally, this flexibility can make it much easier to deal with logistics issues that arise during specialized dual-industry functions or innovative developments.

APIs can also be much more efficient than an EDI. Although this is not always the case, APIs that are designed for specific environments and setups, such as a RESTful API which breaks its data transit into a microservice (more on REST and microservices can be found in the Nordic APIs archives), can result in a bespoke data flow and transit solution that is far more efficient and effective than the EDI process for smaller amounts of data or specifically limited data sets.

The pure simplicity of many API solutions is also a huge benefit. APIs can be extremely simple or extremely complex. EDIs are generally what the EDI is — there’s some room for flexibility, but the differences between one HIPAA-compliant EDI solution and another don’t vary wildly. On the other hand, APIs are typically simpler to develop and deploy, meaning that the API can iterate, change, connect with new systems, and pivot based on business needs at that moment in a way that EDIs cannot necessarily do.

This speed, simplicity, and general usability also allow APIs to be a bit more future-proofed than EDIs. EDI development is often slow and dependent upon regulation and guidelines. APIs can still adhere to these regulations and guidelines while iterating the base transit, data flow, and at-rest storage because of how they’re designed, meaning that APIs are typically much quicker to respond to the future and to adapt to changes in environments such as the global supply chain, a system that has seen massive changes in the last few years.

Drawbacks

APIs have their drawbacks, however. Some of these drawbacks are indeed related to their strengths. In some cases, what makes APIs an attractive solution for general data transit might make them unattractive options for situations where EDIs are the core choice.

The API is not a new concept, but its modern iterations certainly are in comparison to EDIs. For this reason, the API and microservice industry can best be considered relatively young compared to the logistics-centric EDI standards of the 1970s and 80s. Accordingly, many businesses would prefer to stick with their tried-and-tested EDI solutions rather than moving wholesale to the API. While this is not a weakness with the API in theory, it could result in a smaller user base and, thus, a smaller test case of APIs in these broad, interconnected systems.

It should also be noted that web APIs require internet connectivity (or, at any rate, internet-connected devices like the Internet of Things). EDIs were designed to operate on now-antiquated systems to deliver their data, and if the internet was unavailable, there are still standards for functionality to persist. For many APIs, losing internet connectivity would mean completely interrupting interconnected systems.

APIs are also designed as a mode first, and then are given restrictions through guidelines and implementations. EDIs were designed in the inverse — they first had regulations and guidelines and then were developed. This means that APIs were not developed with the security of information in mind in the same way that, say, healthcare logistics EDIs were. This is a negative for many organizations that not only have an ethical and moral responsibility to safeguard information but also a legal one.

Use Cases

Ultimately, EDIs and APIs are two sides of one coin. They are both communication standards with different models of communication. Whereas EDIs are typically protocol-specific, utilizing various protocols depending upon the standard and the industry, web APIs operate across HTTP/S as its core transport protocol, adopting specifications and frameworks instead to guide adherence to communication methodology. EDIs are typically asynchronous based upon a 1:1 connection, whereas APIs can be asynchronous or synchronous and can connect with many clients simultaneously. EDIs typically handle mass amounts of data from a logistics point of view, whereas an API is more effective at handling specific elements of data transit and transformation.

Conclusion

EDIs were designed for one specific thing: inter-entity communication, which required cost reduction and efficiency when dealing with bulk data. APIs, on the other hand, are a general blank slate technology designed for discrete data transformation, with only specific use cases (such as blob transformation, backend surfacing, etc.) handling larger data loads.

That’s not to say that any business that handles logistics must use an EDI. EDIs are useful for certain use cases, while APIs are an equally effective tool best suited for something else. In other words, if an EDI is a flathead screwdriver, an API is a cross screwdriver. Both are equally useful and important, but they handle two types of the same use case.

What do you think about EDIs in comparison to APIs? Do you think one is more effective generally than the other? Let us know in the comments below!