API vs EDI – Choosing the ideal infrastructure for your business

Whether you are new to EDI integration or have been doing EDI for years, you’re reading this because you have an EDI challenge, and you’re interested in using APIs to help you solve it.

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 PRIMER

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.

Leaders and Followers

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 guideline, testing and communication channel 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.

As a follower, achieving EDI integration with a leader can involve complex development, with each leader having different requirements.

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.

How EDI Works

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, elements, qualifiers and loops.

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. For example, below ST in the N1 segment means Ship-To Address. You could also see a qualifier like SF (ship-from) or BT (bill-to).

Segments can loop as well. This means that you can have a segment appear multiple times, depending on what the trading partner guidelines describe. In the screenshot below, we can see that the N1 segment appears multiple times. This means that there are multiple addresses listed in this 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 PRIMER

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.

Developer Building Blocks

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.

What APIs Do

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.

How APIs Work

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. Methods such as GET, POST, PUT, PATCH, and DELETE can be performed by APIs using HTTP protocols to perform create, read, update or delete operations. Unlike EDI, API transactions allow the response to include hypertext links to related resources as well as robust response detail.

ADVANTAGES AND DISADVANTAGES OF EDI VS API

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.

EDI Advantages and Disadvantages

The “benefits” of EDI have helped the business world become more efficient, beginning a half-century ago:

• Secure communication with EDI-integrated trading partners
• Dynamic transfer of business documents
• Buy products, sell products, move products
• Transmit information about payments or deliveries
• EDI replaces phone calls, mail, email, and fax
• Savings in time and cost, reduced errors, and lower transaction costs vs. paper

The “downsides” of EDI have challenged companies and developers for decades:

• Complex integration with extended development times
• Typically requires EDI-specialized knowledge
• Difficult for companies with limited IT resources
• EDI software needs to be integrated with business systems such as ERP
• Different partners can have different versions of EDI transactions
• Long integration timelines can delay supplier onboarding
• No detail included in EDI transaction response

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.

API Advantages and Disadvantages

The “benefits” of API technology hinge on speed, flexibility, reusability, and the use of modern tooling.

• Connectivity of different applications, systems, servers, data, and software
• Real-time feedback
• Detail included in API transaction response
• Self-service model allows independent deployment
• Ability to publish requirements to the Internet
• Reduced capacity for human coding errors
• Use of common Internet protocols including HTTP and HTTPS
• Greater programming familiarity for modern development teams
• Broad of open-source solutions
• Use of reusable building blocks
• Developers can make changes without impacting other services
• Layered architecture facilitates caching and reduces latency
• Encapsulation of legacy systems

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.

BREAKDOWN OF TRANSACTIONS: EDI VS API

EDI

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

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.

THE NEED FOR EDI

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 MOVE TO APIs

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:

• Self-service model
• Able to publish requirements on the internet
• Easy authentication
• Real time feedback
• Documentation
• Iteration
• Developer friendly
• Modern tooling and languages

THE IDEAL EDI SYSTEM – API and EDI

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.

PREVIEW AN IDEAL SYSTEM HERE

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.