Whether you are new to EDI integration or have been doing EDI for years, you might be reading this because you have an EDI challenge, and you’re interested in learning how you could use APIs to help you solve it. You might be here to learn what an API is. We’ll cover both. There has long been a debate about API vs EDI. We will go into the differences between the two approaches and talk about how modern EDI software companies are future-proofing traditional EDI integrations with an API approach.
Maybe you’re a product manufacturer who just got your first order from a national retail giant. It’s a milestone for your business – but along with the excitement comes the requirement to do EDI transactions, and you don’t have a lot of time to put EDI in place.
Perhaps you work for a company that is well-established in EDI and are frustrated by the ever-present complexity of trading partner integrations. You are wondering if you can send and receive EDI transactions using only API technology in hopes of bypassing EDI entirely.
Finally, as an IT developer, you may be interested in how an API platform can speed the integration of a new ERP or CRM system.
If you are involved in transportation management systems (TMS), supply chain integration, e-commerce, business process automation, vendor inventory management (VMI), enterprise resource planning (ERP), or any number of other practice areas, you likely find yourself straddling the worlds of EDI and APIs. There are demands on your business to trade traditional EDI transactions as well as to integrate with APIs. In this article, we will discuss the differences and how to effectively leverage both as you scale your business.
EDI (Electronic Data Interchange) became a standard for business communications at about the time Value Added Networks (VANs) made their debut. The first cross-industry EDI specifications were published back in 1975, paving the way for companies to exchange data in standardized formats.
EDI had its roots in military logistics, with the introduction of data exchange standards to support the vast amount of goods transported during the 1948 Berlin airlift. Beginning in the 1970s, transportation companies, the grocery and food industry, automotive manufacturers, and large retailers started adopting EDI.¹ Soon, major companies demanded EDI connectivity of all their suppliers and trading partners. The age of syntax‑neutral, standards-based, data exchange soon became ingrained in mainstream business.
While EDI allowed large companies (“leaders”) to reduce costs by eliminating paperwork, faxes, and phone calls, it was expensive and complicated for smaller companies (“followers”) to implement. Leaders set the requirements, demanding that followers trade with them according to the specs the leaders define. For new trading partners, EDI integration required costly software, robust IT resources, and the use of specialized VANs. To make matters worse, small companies had to perform separate EDI integrations for each large customer since everyone used slightly different EDI standards.
EDI helps companies reduce costs, increase speed, eliminate errors, and improve intercompany relations by replacing mail, fax, and email in the traditional exchange of documents. Instead of manually transacting, EDI allows companies to do business together automatically.
EDI documents are transmitted to an application on a receiver’s computer, where processing (translation) can begin immediately without human involvement. Purchase orders, invoices, advance ship notices, bills of lading, customs documents, inventory reports, shipping status documents and payment documents are examples of documents that are transmissible via EDI.
With the advent of the Internet, new protocols have provided alternatives to the use of VANs for the communication layer of EDI. As a result, some large EDI users have developed their own online exchanges using Web-like markup languages instead of rigid EDI documents. Technologies like XML, PEPPOL, cXML, OASIS and ebXML have had limited success in their efforts to improve EDI.
It’s quite impressive how much data can be sent in an EDI transaction with so few characters. The standards set up 50+ years ago were focused around sending very high value content in really small payloads.
Documents prepared by a business must be translated into an EDI format using appropriate segments and data elements. Specialized mapping expertise is required to define how your internal business data is correlated to EDI data. Software can be used to assist in X12 and XML EDI data translation.
Each leader has their own EDI requirements. This has created much of the trading complexity that exists in the supply chain today. Not only does every leader have their own requirements, but there aren’t any guarantees that their guidelines must follow the standards set by the ANSI X12 standards.
EDI is generally classified as two different standards. X12 is widely adopted in North America and EDIFACT is leveraged in Europe and APAC. These standards are used to provide a governing schema for how to trade with another company. The standards are defined by unique characteristics that make EDI what it is. EDI transactions are made of multiple segments.
Segments can loop as well. This means that you can have a segment appear multiple times, depending on what the trading partner guidelines describe.
Segments contain unique elements. These elements are position based. In X12 they are separated by an asterisk.
Diving deeper into an EDI transaction, we encounter the concept of “qualifiers.” Qualifiers are unique identifiers that describe the data in the transaction.
Following translation, the business documents are transmitted to a partner using a communication channel like AS2 or another secure internet protocol such as SFTP. In some cases, a third-party EDI network provider or VAN provider is used to transmit the documents. After receiving the EDI documents, the receiver then uses EDI translation software to convert the documents to data in their internal formats.
API (Application Programming Interface) technology traces its roots to the 1940s, but the modern API resulted from the Internet. Modern APIs were made possible by the REST (Representational State Transfer) architectural style, which created a framework for the architecture of the World Wide Web and established guidelines for creating stateless, reliable web APIs.
REST addressed behavioral constraints, scalability, uniform interfaces, independent deployment, and created a layered architecture to facilitate caching, reduce latency, provide security, and encapsulate legacy systems.
Developers can use APIs to create complex processes, reusing codes instead of developing new code for each process. Thus, APIs are like building blocks, allowing development teams to deliver with speed and flexibility for faster supply chain integrations. As an alternative to traditional EDI development tools, APIs allow companies to access web-based software to communicate with their trading partners.
APIs exist to support integration by allowing applications, devices, and servers to talk with each other. APIs act as intermediaries between applications. An API relays a request to an application then delivers a response back to the requestor.
APIs transmit machine-readable information that allows work to be performed without human intervention. APIs make it possible to integrate many different systems – such as Customer Relationship Management (CRM) systems, databases, Enterprise Resource Planning (ERP) systems, and other types of management systems – helping companies become more agile and responsive to other organizations.
RESTful web APIs typically use HTTP methods to access resources via URL-encoded parameters, and utilize JSON or XML to transmit data. Requests made to a resource’s Uniform Resource Identifier (URI) elicit a response with a payload that is formatted in HTML, XML, or JSON. Operations such as GET, POST, PUT, and DELETE can be performed by APIs using HTTP protocols. Unlike EDI, API transactions allow the response to include hypertext links to related resources as well as robust response detail.
EDI was originally designed with standardization and automation in mind. EDI is a deeply rooted, code-based framework for the exchange of business data. It has a reputation for being difficult to implement, requiring significant development resources and sometimes months of development for business partners to achieve the levels of integration necessary to conduct business. The reason for this complexity is that it takes an EDI expert to interpret EDI requirements. These requirements are different for each leader. If you’re a follower who needs to integrate with leaders, you need to understand how to read these requirements before you can begin.
API technology was born in the Internet era, using a uniform interface and hypertext parameters. API technology allows rapid development, high reliability, and the ability to reuse components. On its own, API technology enables companies to automate many aspects of doing business with their trading partners, without the need for additional technology infrastructure. In terms of supporting EDI integration, API technology offers advantages for development teams and plays a growing role in EDI integration strategies.
The “benefits” of EDI have helped the business world become more efficient, beginning a half-century ago:
The “downsides” of EDI have challenged companies and developers for decades:
EDI integration often requires that IT teams have experience in EDI. Since EDI documents can be transmitted using any methodology agreed by the sender and recipient, a variety of programming technologies are used – including Modem (asynchronous and synchronous), email, AS1, AS2, AS4, OFTP, OFTP2, Mobile EDI, and other technologies – as well as standardized Internet protocols.
The “benefits” of API technology hinge on speed, flexibility, reusability, and the use of modern tooling.
Given that APIs allow for fast, agile, and adaptable integration using modern development tools, the main downside to APIs is that they are more unstructured than EDI. For example, endpoint names, authentication, schema, and integration requirement documentation for a transaction type will differ from one trading partner to another.
Open source and reusable tooling allow API developers to evolve and customize projects. APIs deliver constant connectivity to connect web applications, enabling self-service, real-time feedback, documentation, layered security, authentication, and web-published requirements.
|Communication Channel||Hypertext Transfer Protocol|
|Not understood by machine||Understood by machine|
|Response||997 – Accept or Reject||HTML, XML, JSON|
|No transaction detail provided||Robust transaction detail provided|
|Requirements||Published via PDF||Published via URL|
EDI transactions use proprietary communication channels and payload frameworks. Guidelines are not machine readable. 997 response returns Accept/Reject only with no error explanation or detail.
API transactions utilize modern transfer protocols and payload builds. Guidelines and requirements are machine readable and published to the web. Response is robust, providing transaction detail or explanation of errors.
Is it possible to completely replace EDI with API technology? In theory, yes, two companies could decide to do this. But when it comes to weighing EDI vs API technology, it’s not practical to think that you can trade only in one format or the other.
A handful of retailers (with Walmart and Amazon leading the way) now provide an API that lets trading partners send transactions without EDI software. But these cases are the exception. Most large retailers still require EDI transactions.
EDI will not go away in the foreseeable future because this sea-change would require all trading partners in a supply chain to upgrade their technology to handle an API transaction. This is too much to ask of a supply chain, meaning that EDI is here to stay.
If you are doing business with partners who require EDI, you have no choice. The only question is how you’re going to integrate your business systems with EDI. The modern way is to connect your business systems to the EDI system using API technology.
Thanks to APIs, there are easier pathways to EDI integration than ever before.
The good news is that more and more large companies are developing API options for supply chain integration or plan on doing so soon. Their reasons for moving to API-based integration are as numerous as the benefits of API technology itself:
The ideal EDI system would offer a modern API for connecting to ERP, CRM, and other internal business systems. Any participant in the supply chain could connect their business systems to a cloud solution using API technology and be able to send EDI transactions to any other company in the network.
This cloud solution would provide prebuilt EDI connectivity to every company in the supply chain – retailers, manufacturers, and all connecting logistics and transportation providers. The service would shield users from the complexity of the EDI transactions since the transactions would be prebuilt.
The ideal EDI system would also allow users to leverage a mix of APIs and EDI technology. The benefit to a business is the ability to bridge the company’s internal systems to modern infrastructure and handle the legacy requirements of EDI through this modern system.
Because of this combination of APIs and prebuilt EDI transactions, the length of time it would take to implement this system and onboard new trading partners would be dramatically reduced.
DISCOVER THE DIFFERENCE
No More EDI Mappings
Connect once to our API and we’ll validate, translate and communicate your EDI data.
Fastest Trading Partner Onboarding
Shorten the testing feedback loop. Real-time data validation against your trading partner guidelines.
Reduce Your EDI Costs
Replace your legacy infrastructure and reduce your time spent on enabling and managing trading partners.
Work with EDI Experts
Our team is made up of EDI veterans. We’re here to solve your EDI problems for good.
Complex 1:1 Integrations
Hundreds and thousands of point-to-point partner integrations
Long Onboarding Times
Partner requirements gathering and testing iterations take a long time
Hard to stay in compliance with partner guidelines resulting in chargebacks
Very Slow Issue Resolution
Poor visibility into EDI exceptions and long resolution times
An ideal EDI system is already being used by forward-looking companies today. Orderful is a cloud-based system with modern APIs to connect business systems and trading partners, making EDI integration simple.
The system is already in use by more than 1,000 retailers, carriers, 3PL providers, and manufacturers. Companies are using this cloud-based EDI platform to reduce complexity, accelerate onboarding, reduce costs, and make more efficient use of internal resources.
Using this system, the time it takes to onboard new trading partners has been reduced from months to days.
Learn more about Orderful Cloud EDI Software.