¾«¶«Ó°Òµ

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, , 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. 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 . 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 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 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 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.