Skip to main content
The EDI API runs retailer and 3PL document exchange for one tenant: configure a trading partner, process what they send you, generate what you owe them — an 856 ship notice, an 810 invoice, the labels and packing slips a shipment needs — and reconcile what actually happened against what the documents said.
This reference is generated from the document the running server publishes — version 0.4.0. The same 116 operations are exposed as 117 MCP tools for agents, so a call here and a tool call there hit the same handler.

​
Where to start

Register a partner

A retailer or 3PL, its identifiers, its transport, and the overlays that adapt each transaction set to what that partner actually accepts.

Generate an 856

Ship notices, invoices, POs and the rest — ten X12 sets and the EDIFACT INVOIC and DESADV, each validated against the partner’s profile before it leaves.

Process an inbound document

Raw X12 or EDIFACT in, a parsed, validated document out — with AS1/AS2 ingress helpers for partners who deliver that way.

Reconcile and recover

Lifecycle traces, business reconciliation, the status board, and the deductions workflow that turns a short-pay into evidence and a dispute.

​
How the pieces fit

  1. Partners hold the contract: who they are, how documents reach them, and which retailer profile and certification pack apply.
  2. Inbound turns what a partner sends into documents you can act on; outbound turns your orders and shipments into documents they will accept.
  3. Operations is everything after the wire — evidence bundles, replay, reconciliation, delivery status, dead-letter handling, and deductions.
Run the sandbox flow before a live partner sees a document. The MCP server’s edi_demo_order_to_invoice_flow tool walks an 850 through 997, labels, 856 and 810 to a retailer 997 acceptance, end to end, against your configuration — see the EDI MCP server. There is no single REST endpoint for the whole flow.