OpenAPI EDI Format

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:

EdiNation X12 837P OpenAPI example


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.

Was this article helpful?
0 out of 0 found this helpful