EDI vs API - What small business needs to know

Each has its place, make sure you know which is appropriate for your requirements.

There are many paths available when seeking to integrate multiple systems, but at the forefront of it all is ROI, it’s all that matters, so let’s explore the EDI vs API approach to integration.

At BizAutomation our philosophy is crystal clear. Integrate only “non-core” systems in order to minimize data duplication, manual entry, and complexity. So for example, Accounting and CRM are core, inventory is core, they should all be part of a suite on the same database (which benefits from all the goodness of data sharing, referential integrity), so there’s always a single version of the truth (e.g. a single customer record shared across all the modules that can use the data). But if you want to get shipping rates from FedEx, that’s non-core because FedEx rates originate at FedEx, not your business system.

When it comes time to integrate with 3rd party non-core data, there seems to be a controversy in some circles about using an API vs EDI to get the job done. Some miss-informed articles  even make it sound as if API is the next version of EDI, but these two are intended for completely different purposes, so what you’re really doing is comparing apples and oranges. Don’t beleive anyone that makes it sound as if one is superior to the other. It would be like comparing a helicopter to an automobile simply because both are forms of transportation.

EDI is a specification that defines how two systems must exchange data electronically and (most importantly) universally, which means it’s going to be the same across every system that adherses to it. In the U.S. it’s governed by a protocal referred to as X12 which assigns specific numbers to documents (810 is an Invoice, 850 is a Purchase Order, 856 is a shipping confirmation document that informs the seller that a shipment has left the warehouse, and the list goes on). An 810 Invoice is going to contain a common denominator set of fields / codes that contain data expected within an invoice, such as line item name, description, etc… and it’s universal across all companies that integrate using it.  That’s right, if you’re sending Walmart, or Target, or whomever an invoice via EDI, the item name, description, qty, and other elements typical of an invoice, are going to be exactly the same because they’ll confirm to the X12 EDI standard.

An API on the other hand is not universal. It’s software application specific, and even the code used is not specific (there are JSON, XML, and other ways of describing the data). This means that if you want to send invoice data via API, then you have to know the software system used by the company sending / receiving it and code specifically to it. SO while an API is way more flexible, it’s ideal for custom integration between two software applications (which according to BizAutomation should not be “core” modules). Another advantage is that you typically don’t have to connect directly to the application without going through a 3rd party “hub” that interprets the preferences of one of the 2 sides exchanging data (If you do, then each hub will be requiring different API integration from you). Yes, that 810 EDI Invoice has data that comes from the same ingredients, but Walmart might want an SKU, and Target might not, this is where these EDI MSPs play a role, particularly with the big box retailers because they already know what they want in terms of mapping, making things plug n play. This also means that once  you integrate with an application’s API you’re highly dependant on that application and can’t transfer the integration work to another application (or API hub) without rewriting the code.

Now, if EVERYONE used the same app to run their business, there would be no need for EDI because you’d just code to a single API and call it a day, but this isn’t how the real world works. And that’s why EDI is key for its role.

Now do you see why the comparison makes no sense ?.



Add comment

  • Comment
  • Preview