by RSSBus Marketing | January 28, 2019

API vs. EDI: Why Not Both?

Since the early 70s, Electronic Data Interchange (EDI) has been the gold standard for exchanging information for supply chain workflows. EDI establishes a set of messaging standards for transferring data from system to system in electronic format without the need for paper and manual processes. But while EDI has seen some advances — including improvements to X12 structures and to encryption algorithms in AS2, as well as new protocols such as AS4 — it has only seen few major changes.

Today, organizations are increasingly using newer technologies such application programming interfaces (APIs) to automate communication between processes, applications and even businesses, even using Blockchain to provide traditional functions, such as non-repudiation.

In this post, we’ll concentrate on APIs, which enable new types of interaction and transactions by exposing functionality and services. Applications can consume the services of another application to enable data exchange. As more and more businesses use applications, such as NetSuite, that use APIs to communicate with other applications internally, they are considering using APIs to communicate with external partners as well.

But can APIs truly replace EDI?

Whether an organization opts for EDI, APIs or some combination of both depends on the use case.

Advantages of EDI

EDI often uses a hub and spoke model where a larger trading partner, such as Walmart, is the hub and the smaller players, such as Walmart suppliers, are the spokes. The hub typically dictates the specifications and the formats that smaller partners must use to communicate. Thus, if you’re a smaller company working with a larger trading partner, you may be at the mercy of your partner’s communication standards.

For larger organizations that may deal with thousands or millions of transactions, EDI continues to offer several advantages that include:


EDI provides standard protocols (such as X12, EDIFACT, EANCOM, and others) for document specifications set by third party governance organizations (including ANSI ASC X12, the EAN General Assembly, the United Nations, the Organization for Data Exchange by Tele Transmission in Europe and others). These standards provide a strict framework for well-coded business processes where all parties agree on specific formats for business documents being exchanged, such as invoices, purchase orders and shipping notices. For example, each partner can specify the fields they want to include on an invoice, such as billing/shipping address and PO numbers, and these fields will always appear in the same format in the same location on the document.

In contrast, APIs have no well-defined structure — organizations can use JSON to create any structure. The fact that few specifications exist around what the communication should look like between businesses with an API approach means you’ll need more communication with your trading partners to develop communication standards.


With EDI, vendors perform considerable industry-wide interoperability testing to ensure software is compatible across vendors and to eliminate communication problems. For example, vendors undergo Drummond testing four times each year for AS2 and AS4 secure messaging products. In contrast, APIs are not regulated. No processes exist to ensure that vendor solutions are compatible with one another.


EDI has numerous well thought out and standardized built-in security mechanisms, making it one of the safest ways to transfer data. Encryption and signing ensure that only pre-defined, authorized users can access data. Non-repudiation capabilities — receipts and acknowledgements at various layers across transactions — are available to accurately track use. APIs do not inherently include the same levels of security as some of the traditional EDI protocols. You must build security into each solution and create workflows around non-repudiation.

The bottom line is that EDI continues to make the most sense for large organizations with tremendous numbers of transactions because it is highly reliable and, if something goes wrong, it provides audit trails for traceability.

When to Consider APIs

While APIs will never fully replace EDI for the reasons just described, they have clear use cases. Many smaller businesses find they can use APIs as a steppingstone to automated B2B communications. Alternatively, APIs can replace and automate existing communications systems, such as WebEDI, which provides a portal where partners can manually fill out shipping forms online.

For these use cases, APIs provide several advantages over EDI.

Rapid development

EDI uses complex, opaque document formats and is thus used primarily by EDI specialists. In the past, API development was also code heavy, fragile, time intensive and error prone. But today many developers use technologies, such as JavaScript Object Notation (JSON), Open Data Protocol (OData) and Swagger OpenAPI Specification, that make API creation faster and easier.

  • JSON is a widely used and easily understood syntax for storing and exchanging data.
  • OData is an open protocol for sharing data that breaks down data silos and has helped standardize APIs and simplify API development.
  • Swagger is a open-source framework built to create machine-readable definitions for APIs.

Solutions such as RSSBus Connect also offer connectors that can connect to a database and make it easy to create APIs.

Scalable & Agile

APIs make it easy to scale and distribute load for large scale business processes. They also make it easy to quickly adjust business processes, so your business can react to new initiatives much faster.


APIs can easily connect to applications, databases, other systems. They also are generally much more lightweight, making it easy to connect from mobile devices, etc. Traditionally, EDI systems are much more heavyweight and require many more resources to run and manage.


There is an abundance of technologies that make it easy to create and consume APIs. In addition to technological advancements, it is also very easy to find people capable of building and managing your API processes, whereas EDI is a much more specific skill and more difficult to recruit staff members to manage.

Why Choose? Use Both

In some cases, you may want to use APIs with EDI to add capabilities it doesn’t natively provide. You may have some partners using EDI and other smaller partners that don’t have a formal EDI process in place. In this case, you could use APIs to integrate with your smaller partners and EDI for the rest of your partners.

You can also use API-based transactions to implement complementary services that are not included in EDI standards, such as services that provide visibility into transport tracking, volume statistics, SLA and error rates. You can even use APIs to provide interactive handling of exceptions such as transport cancellation and exception notifications.

RSSBus Connect Simplifies EDI and API Data Exchange

RSSBus Connect offers API connectors that make it easy for you to produce and consume APIs for business processing with the click of a button. Because RSSBus Connect also includes EDI connectivity, you can access EDI and API connectivity on the same platform. Use what works best or take an API approach with some partners and an EDI approach with others.

Contact us to learn more about how you can create APIs or EDI connections with RSSBus Connect.