The following table highlights the differences and complements between EDI and API data integration on systems:
|Partner-oriented||Application-oriented and user-oriented|
|Industry standards-based||Technical standards-based|
|Business application friendly||Mobile device friendly|
|Medium length deployment||Fast deployment|
|Standardized message formats (orders, invoices, shipment notices)|
Driven mainly by standards bodies
|Ad-hoc message formats. EDI formats can be used in principle, but only applicable for basic implementations.|
Driven mainly by the service implementer
|System of records||System of engagement|
|Partner onboarding requires a technical and business workflow||Partner onboarding is typically simpler|
|Services are well defined and do not evolve regularly||Services are defined via APIs, they require a full-fledged lifecycle management|
|Business agreements are often required||Usage conditions are defined unilaterally by the APIs|
|SLAs are commonplace||SLAs are not a top of mind issue|
|Typically used for order-to-cash and similar supply chain cycles, as well as multi-chain interoperability||Typically used for data and service exposure|
|Value is in efficiency in partner relations||Value is in both partner relationship and service monetization|
|Owned by supply chain and IT departments||Owned by Chief Digital Officer and IT departments|
What is EDI?
EDI (Electronic Data Interchange) is a proven technology since the early 1980s for the exchange of information between enterprises and organizations. EDI formats such as EDIFACT, ebXML and EDIG@S are the standards for data exchange in major industrial sectors such as transport and logistics, distribution, manufacturing and utilities. The use of EDI is prevalent in supply chain processes.
How does it work?
EDI provides a strict framework for well-coded business processes where all parties agree on specific formats for business documents to be exchanged such as invoices, purchase orders, shipment notices. EDI also defines advanced rules for dealing with content, and the relationships between items in a document—such as an invoice number or the amount billed.
EDI exchanges, historically present in the supply chain industry, allow for a solid structuring of data, especially for B2B exchanges. However, EDI is not fit for integrating different vertical software tools (CAD / CAM, PLM, MES, etc.) which are not natively designed to communicate with one another, nor with the millions of IOT objects, nor with the sensors, manufacturing robots, and the products in production which in the future will be equipped with communication mechanisms.
What is an API?
APIs (Application Programming Interface) allow new types of interaction and transactions by exposing the functionality and services of an application to the outside world. The applications can thus consume the services of each other, giving rise to data exchange. Via APIs, customers, partners and employees now have access to business and data services on any device and from any source.
How does it work?
A communication approach by APIs is a good way to respond to new communication requirements for both B2B and A2A settings. Given the volume of data and the disparity of systems involved, efficient data flows within vast industrial ecosystems (tools, machines, production lines spread over several geographical sites, production and logistics entities, etc.) requires a well thought-out rationalization.
The flow of EDI and API
An ideal remedy, in this case, would be to consolidate the integration and exchange environment into a single system that governs the flow of both EDI and API data transactions. Such a system would allow centralized visibility across all data streams, accurate monitoring of enterprise performance, and enhanced security. It would also make it possible to monetize data by ensuring that client and partner commitments are visible and measurable.
Examples of EDI-based transactions include the exchange of standard documents such as purchase orders, shipping notices and invoices. B2B applications via the REST/Web Services API include shipment traceability, exception handling on damaged items, or interrupted processes.
Finally, examples of B2B applications that can use either EDI or Web services or REST APIs include customs declarations (such as manifests) as a consumed service and the corresponding response as an exposed service.
API-based transactions can implement complementary services that are not integrated with EDI standards—services that provide visibility into transport tracking, volume statistics, SLAs, and error rates, for example. They also include interactive handling of exceptions, such as transport cancellation and exception notifications.
Read the related article on AS4.