The format of EDI documents is governed by their implementation guidelines, which in most cases (depending on the standard and the issuing party), describe it only figuratively. Hence, it is human-readable, however, it is NOT in a common, machine-readable form.
OpenAPI input and output types are defined by the Schema Object, which is ready to be machine-processed, widespread across all internal/external APIs worldwide, and supported by almost every programming language.
We combined the two, and now every EDI implementation guideline, regardless of its origin or format, can easily be transposed into an OpenAPI Schema Object. This tutorial will guide you through the steps to achieve that.
View the full OpenApi example here:
NOTE:
This does not imply that EDI will be replaced by OpenAPI, on the contrary, it presents a practicable solution of how EDI and API can work together in a conforming way.
Extend an OpenAPI definition to represent EDI transaction
To model an EDI definition using OpenAPI is to provide an OpenAPI definition file, which is a language-agnostic machine-readable document that describes your API's types.
Supported OpenAPI version
We support OpenAPI 3+.
OpenAPI structure
The only required objects are Component and Schema. All other objects, Info, Security, Tags, Paths, Servers are ignored.
Resolved or unresolved
We only support resolved OpenAPI schemas. All objects that contain one or more other objects must be defined using references to those objects using the Reference object.
Case sensitivity
All values in the custom extensions are case sensitive and must be in upper case.