EDI vs API: What Should Retailers Choose?

When retailers decide to start a marketplace or dropship program, one of the first decisions they need to make is how they will connect with their suppliers.

It’s a decision that comes down to two options: EDI or API? We’ve seen our retail partners get bogged down by this question all the time. 

What they might not know is the world of B2B trade is transforming itself from a world where EDI is the main basis of communication to one where APIs will take its place. In this article, we’ll share what these protocols are and which of them makes sense for your B2B trade operations. 

What is EDI?

EDI stands for electronic data interchange. It was invented over sixty years ago to enable members of the aircraft assembly supply chain to share information in an electronic format with each other. 

Over time, other industries adopted it as their industry standard to speed up communication among trading partners. It’s used today for a variety of purposes, including as the basis for the SWIFT system in banking, for insurance claims, as a way of communicating information about goods in transit between shippers, and more. 

EDI is actually a protocol level standard for communicating business transactions, rather than a programming interface. That means the interface actually connecting EDI to your systems can vary in form and often requires some amount of your own effort to make EDI possible to do (this is where third-party EDI systems and EDI solutions come in). 

EDI files contain information about business transactions, including invoices, purchase orders, inventory inquiries, and shipments. Companies send these files to each other, and then they have to load them in their systems and make meaning of their contents. EDI is the standard that determines what EDI files can contain and how each data point is communicated. 

Businesses that transact with each other in different geographies may use different EDI standards. North American businesses typically use ANSI x12 files while European businesses use EDIFACT files. 

What are APIs?

API stands for application programming interface. It is commonly defined as a ‘software intermediary that allows two applications to communicate with each other’. In practice, it is a way for one software system to talk to another using a consistent data structure in real time. 

API reference documentation is equivalent to EDI in that it makes sense of what data is contained in each field. You can see an example API reference on the Convictional developers site here. The API itself is the technology that is connected according to the definitions in the API reference. It actually does the work of sharing information, compared to EDI which is simply a consistent way to express the state of a business document but performs no computing work. 

The most common pattern used by APIs is representational state transfer (REST). REST APIs are often oriented around the state of a resource. A purchase order could be a resource, so the API is sharing what the state of it is at the time the API is called. This is a different set of rules of engagement to EDI which is a transaction. APIs can facilitate transactions in real time whereas EDI requires a set of documents being sent back and forth to perform the same job.

Key differences between EDI and APIs

It’s easy to get confused by the technical jargon around EDI and APIs. You can get a clearer understanding of these two concepts by recognizing their key differences around flexibility, transactions, and age.

1. Flexibility: APIs are more flexible than EDI. EDI offers standardization, but standardized protocols come at the expense of flexibility. APIs are more flexible, no two are the same, and able to accommodate industry specific requirements than EDI ever was able to, despite its polymorphic data structure. EDI requires a certain data structure for all participants using a particular EDI standard by comparison. 
2. Transactions: EDI transactions are representations of the state of the sender’s system at any given point in time. APIs are both a source of and a repository for transaction data, representing a state that can be changed by the user.
3. Age: EDI was created in the 1960s, while APIs were created in 2000. Even though EDI is an older protocol, it continues to process $5 trillion in trade annually. We expect that usage of EDI to continue for a decade or more before being phased out in favor of API-based integrations.

Another helpful way to differentiate between EDI and APIs is by comparing how they transmit data between systems. For example, take the use case of inventory updates. Both APIs and EDI are capable of being used for sharing information about the inventory availability of a product. 

In the case of an API, the information may live under a product, where inventory is listed for each variant. So you can get a bunch of products at once, or just one, and then look at the inventory per variant of the product via API call. 

In EDI, things are typically expressed in batches of like things. The X12 EDI document 846 contains information about inventory status within a particular location (or less commonly a catalog). In either case, it shows the inventory availability of various products as a key-value pair. The UPC code represents which product it is, and the inventory count tells you how many there are. Typically, no other data about the products or variants are present in this file, and the file would contain all products regardless of whether they are relevant in that particular case. 

Finally, the API would be able to provide real-time inventory, whereas the EDI document containing inventory would typically be set to run on a cadence and shared in bulk. 

{{CTA-1}}

EDI vs APIs for marketplace and dropship programs

Making decisions about whether to trade with your suppliers through EDI, APIs, or both can be challenging without first having an understanding of the preferred technology of your suppliers. 

We recommend surveying suppliers to understand what their readiness level to connect to you is and what their preferred methods and approaches for this might be. Ask about what methods of sharing product information, orders, order updates and payments are preferred. 

When you do this, you’ll get an overall understanding of the readiness level of your suppliers and the onboarding requirements that will need to be met. You’ll find out whether your suppliers prefer API-based or EDI-based connection paths. 

Even if you find your current base of suppliers leans one way or the other, you should consider what an ideal future state of your supplier mix is. For example, if your current supplier base is made up of modern ecommerce sellers who prefer to connect with you via APIs, will you only partner with modern sellers in the future? If you want to partner with classic sellers as well, you might have to plan for having EDI connection paths as well. 

It’s important to think about what systems exist on your side of the transaction and what the overall surface area of integrations will be. Typically, suppliers are sharing product, inventory, pricing, order update and invoice data with retailers. Retailers are typically sharing purchase orders and payments back with the suppliers. Each of these resources likely exist within one of your systems, and ideally you can keep the system of record for each consistent without having to change it for the sake of enabling your suppliers.

The other consideration is which supply models your suppliers are able to participate in. The two physical world types in the retail trade are either bulk orders (e.g. wholesale or in-store consignment depending on who holds title) and direct orders (e.g. marketplace or drop ship orders, again depending on who holds title). A requirement to enable more supply models will sometimes have implications for the technology required on both sides of the transaction.

With a strong understanding of the requirements of your suppliers and your existing technology, the next step is to bring those two things into alignment. 

Supplier enablement is our preferred approach to solving this problem, which involves connecting to existing systems (e.g. having a light touch in your existing environment) while allowing suppliers to choose the method that works best for them. It avoids having strong opinions about whether to push people down an EDI integration or API-based connection path, and offers connection options that cover as many suppliers as possible. We believe this enables the best outcomes for both parties involved.

Leverage the best of EDI and APIs with Convictional

You don’t have to make a tradeoff between EDI and APIs for your marketplace or dropship program. Convictional gives you the ability to connect with trading partners with any integration method.

• Modern sellers can connect with you with our native Shopify, BigCommerce, and WooCommerce integrations. 
• Classic sellers can connect with you with CSV uploads or EDI x12 files. 
• For sellers with custom systems that need a specialized integration solution, they can connect with us directly via the Convictional API. 

Having the ability to connect with sellers through their preferred integration methods make it more appealing for them to do business with you. To learn more about how we combine API and EDI connections for you, get in touch with our sales team today!

EDI vs API FAQs

Here are answers to the most common questions about EDI vs API:

EDI vs API: which is better?

Our data suggests that about 30% of suppliers in trade relationships forming in 2022 still prefer EDI over modern alternatives. The remaining 70% typically connect via API integrations in some fashion to manage their business processes, but the method can vary significantly between app-like connections (powered by an API under the hood), manual data upload (also powered by APIs under the hood) or direct API connections.

Do APIs replace EDI?

APIs can be used instead of EDI but the difference between them in approach typically means that the “work” has to happen on a remote server in the case of APIs. The API has to be connecting you to something, and not all the context needed to perform a transaction is typically included in a single API response. Rather, APIs are both a source of and repository for transaction data, representing state that can be changed by the user, EDI is simply a representation of state at a given time which can only be changed by the EDI document sender.

Over time we believe that API-based connections will replace EDI, but we believe that enabling all suppliers implies a significant amount of transition effort between now and when that time arrives. The ideal customer experience is not limited by supplier enablement technology, and the ideal supplier enablement technology is one which does not limit which suppliers can participate in a trade program on the basis of the technology they are most familiar with. 

Is EDI outdated?

EDI is still used to process over $5 trillion worth of transactions per year and that number is still slowly growing. We expect that usage of EDI to continue for a decade or more before being phased out in favor of API-based approaches to exchange data. EDI is outdated in the sense that the standard in use (e.g. the ones companies actually have implemented in practice) is often from the 1990s or 2000s depending on the area of the world in which you’re based. Most North American companies are still on the 1997 standard of X12 EDI, which is certainly outdated. 

What is replacing EDI?

EDI is a common understanding of what each type of business document means and a consistent way to represent that understanding. APIs are more flexible, have more functionality, and are able to accommodate industry specific requirements than EDI ever was able to despite its polymorphic data structure. It is likely that each industry will start to standardize over time the data models involved in performing transactions for information exchange between business partners, but we do not expect to ever again see standards in the way that EDI standards were formed by committees of large companies in a particular sector.

Is EDI an API?

EDI is not an API in the sense that it does not allow applications to be programmed on top of it. Through platforms like Convictional, you can make use of EDI documents and the data they contain through an API, but the data is being stored in a combination of EDI files and databases. In the future, it’s likely that EDI, the data format standard and APIs as a way of connecting business systems together using the internet will converge on each other such that you’ll be able to manage your EDI documents through an API. Convictional offers such a solution today which makes it easier to use EDI in the areas that we work. 

EDI vs API in supply chain

Businesses with significant supply chain management processes that use EDI have been slow to transition to APIs. Many EDI documents are still in active use in freight and supply chain contexts, including the 200 and 300 series of the X12 standard. It is likely over time that the number of meaningful things communicated among supply chain participants using EDI will decrease while the overall amount of data shared increases.