EDI Transaction Sets

Current X12 and EDIFACT direction/version inventory, outbound API coverage, and partner qualification boundaries.

Use GET /v1/x12/capabilities for the deployment’s declared X12 sets and versions, and GET /v1/capabilities for platform feature discovery. A codec or declared set does not establish that a particular partner’s full guide has been qualified.

X12 inbound

The reviewed translator supports these 23 transaction types:

Business area	Sets
Purchase orders and responses	850, 860, 855, 865
Shipment, inventory, and warehouse	856, 846, 852, 944, 945, 947
Billing, remittance, and deductions	810, 812, 820
Catalog and application messages	832, 824, 864
Freight and routing	210, 214, 990, 754
Healthcare eligibility	271
Functional acknowledgments	997, 999

TA1 is also handled at the interchange-envelope level. Received 997/999 and TA1 are acknowledgment evidence, not new purchase orders or proof of payment.

X12 outbound

Direct generation routes take typed JSON and return enveloped X12:

POST /v1/edi/outbound/204/{partner_id}
POST /v1/edi/outbound/270/{partner_id}
POST /v1/edi/outbound/753/{partner_id}
POST /v1/edi/outbound/810/{partner_id}
POST /v1/edi/outbound/832/{partner_id}
POST /v1/edi/outbound/846/{partner_id}
POST /v1/edi/outbound/855/{partner_id}
POST /v1/edi/outbound/856/{partner_id}
POST /v1/edi/outbound/865/{partner_id}
POST /v1/edi/outbound/940/{partner_id}
POST /v1/edi/outbound/943/{partner_id}

The outbound capability inventory also includes generated 997 and 999 acknowledgment builders. It does not imply a public JSON-generation endpoint for every listed builder. 850/860 builders used in synthetic retailer fixtures are not supplier outbound offerings.

Envelope versions: 004010, 005010, 005020, 005030, 005040, 005050. Source golden vectors cover 4010/5010; later versions share envelope rules without dedicated vectors. Qualify transaction content, version, qualifiers, and guide requirements together.

EDIFACT

Inbound syntax detection recognizes ISA, UNA, and UNB framing. The ten-type internal baseline covers ORDERS, ORDCHG, ORDRSP, DESADV, INVOIC, INVRPT, RECADV, REMADV, APERAK, and CONTRL. Validation supports EDIFACT as well as X12.

Outbound message	Endpoint
INVOIC	/v1/edifact/outbound/invoic/{partner_id}
DESADV	/v1/edifact/outbound/desadv/{partner_id}
INVRPT	/v1/edifact/outbound/invrpt/{partner_id}
CONTRL	Generated by inbound acknowledgment handling

EDIFACT date/time formats and invoice amounts are validated explicitly. Preserve decimal strings and supported time precision; do not silently coerce malformed dates or recompute source totals in an integration.

Validate and send

POST /v1/edi/validate/{partner_id} dry-runs wire against that partner’s guide; POST /v1/edi/parse is an X12 parser/debugging route. Actual inbound processing can record rejections and return TA1, 997, or CONTRL evidence. Inspect the full business verdict.

For an 856, use the documented orders[] structure with items[] or cartons[]; shipment and PO identities are not interchangeable. Use real allocated SSCC-18 values, exact quantity/price strings, and the same labels physically attached to the cartons.

Reviewed order sends cover 855/856/810 from current PO evidence. MCP exposes fourteen direct outbound tools, while the JavaScript SDK’s outbound() allowlist has twelve; use REST for 753/INVRPT through that SDK version. All outbound integrations need original-request recovery and actual partner testing.