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.

In this post, we'll concentrate on APIs, which enable new types of interactions and transactions by exposing functionality and services. Applications can consume the services of another application to enable data exchange. As more and more businesses implement applications, such as NetSuite, that use APIs to communicate with other applications internally, they are considering APIs for communications 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

One popular approach to EDI uses the hub and spoke model, where a larger trading partner, such as Walmart, is the hub, and smaller partners, such as 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 larger trading partners, they will often set the EDI standards you will use and somewhat guide your choice of technologies.

But in addition to helping you meet the requirements set by larger partners, EDI does offer several key advantages when compared with APIs.

Standardization

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 common messaging formats like 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 agreen on messaging structures and data flow.

Interoperability

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.

Security

EDI has numerous well thought out and standardized security mechanisms built-in, 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. While point-to-point messaging can be secured with SSL/HTTPS, you must still create workflows to support non-repudiation.

The bottom line is that EDI continues to make the most sense for large organizations with high transaction volumes 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 stepping stone to automated B2B communications. Alternatively, APIs can replace and automate existing communications systems, such as web EDI, which provides a portal where partners manually fill out shipping forms online.

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

Rapid development

EDI relies on 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 an open-source framework built to create machine-readable definitions for APIs.

Solutions such as CData Arc also offer database ports that 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 organization can react to new initiatives much faster.

Connectivity

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.

Low-Cost

There is an abundance of technologies that make it easy to create and consume APIs. In addition to benefitting from these technological advancements, it is also easy to find people capable of building and managing your API processes, whereas EDI is a much more specific skill and is more difficult to find staff 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 use 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.

CData Arc Simplifies EDI and API Data Exchange

CData Arc offers API connectors that make it easy for you to produce and consume APIs for business processing with the click of a button. Because CData Arc 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 CData Arc.