What Is Amazon EDI?

Amazon EDI is the exchange of business documents between Amazon Vendor Central and a vendor, in the ANSI X12 format, over a direct machine-to-machine connection rather than through a web portal. Amazon is the buyer: it issues purchase orders to you, you confirm and ship against them, and you invoice Amazon for what shipped.

The documents themselves are standard X12 transaction sets, the same numbered documents used across US retail. What is specific to Amazon is which documents it requires, which fields it validates, and the rules each of its programs applies.

These are two different commercial relationships, not two names for the same thing, and they run on different technology.

On Vendor Central you are a supplier. Amazon is the buyer of record, it owns the customer relationship, and the integration is EDI. On Seller Central you are the seller of record, you set prices and own the listing, and the integration is Amazon's Selling Partner API rather than EDI.

This matters before anything is built, because the answer decides whether you need an EDI integration or an API one. A vendor doing both needs both, against the same product catalogue.

No. Amazon sellers on Seller Central, often called 3P sellers, connect through Amazon's Selling Partner API (SP-API), not EDI. Orders, inventory and FBA shipments all run through it.

EDI is for suppliers who sell to Amazon through Vendor Central. If you sell on Amazon yourself, see Amazon SP-API integration instead.

Both are Vendor Central EDI programs and both can run on one account, but they describe different physical flows.

In Wholesale, Amazon buys stock and you ship it in bulk to an Amazon fulfillment center. Amazon then sells and ships it to the customer. Where the freight is collect, Amazon arranges the carrier, which adds a routing exchange before the shipment moves.

In Direct Fulfillment, Amazon takes the customer order and passes it to you as a dropship order, and you ship that single order straight to the customer's address. There is no bulk shipment into Amazon and no Amazon-held stock.

A Wholesale cycle uses a predictable set of transaction sets. Each has one job, and which ones you exchange depends on what Amazon requires of your account. For what each document does across all trading partners, see EDI transaction sets explained.

• 850 Purchase order. Amazon orders stock from you. Starts the cycle.
• 855 Acknowledgment. You confirm what you can actually fulfil, with quantities and dates.
• 753 Routing request. On a collect shipment, you send pallet and carton details to request freight.
• 754 Routing instructions. Amazon replies naming the carrier and pickup. Only then does the ship notice go.
• 856 Advance ship notice. What is on the shipment, matching the order and what physically shipped.
• 810 Invoice. Bills Amazon for what shipped, matched line for line against the ship notice.
• 846 Inventory advice. Reports stock levels to Amazon on a schedule or trigger.
• 997 Functional acknowledgment. Confirms a document was received and could be read. Its absence is usually the first sign of trouble.
• 824 Application advice. Amazon rejecting a document at the application level, with a reason.
• 812 Credit or debit adjustment. Corrects a billing discrepancy after the fact.

The documents have to travel over something. Amazon supports several transports, including AS2 and SFTP. The connection we run uses SFTP.

You can hold that connection yourself, with the documents built into your own ERP, or go through a provider who holds it for you and hands you a translated file. Both work. The difference is where the mapping and the business rules live, and whether you pay per document.

Onboarding runs in a predictable order. You set up the connection in Vendor Central and exchange technical details. You map each document to your own item, order and shipment data. You exchange test documents with Amazon until they pass its validation. Then you switch to production and watch the first live orders closely.

The mapping is the part you control. The testing and approval steps are Amazon's, and they usually take longer than the mapping work, so plan the sequence around that rather than around your own development estimate.

What Amazon requires, and which fields it validates, is set by its own current documentation and changes over time. Check the current spec for your account rather than relying on how an earlier onboarding worked.

When a document is rejected, look for a disagreement between documents before assuming the file is broken. A ship notice can disagree with what physically shipped, for example on carrier, cartons or quantities changed at the warehouse after the order was confirmed.

On collect shipments, an appointment that does not match what was actually scheduled can be rejected on that mismatch. Invoice lines that do not match what shipped can be rejected separately, for example when a substitution never reached the order record. And a missing 997 is not a rejection at all: it can mean the document never arrived.

There is a longer walk-through of these cases, with how they get diagnosed, in why an 856 ASN gets rejected.

We build Wholesale and Direct Fulfillment as separate integrations inside your own ERP, connected directly to Amazon. See Amazon EDI integration for how that works, or get in touch with which program Amazon has enrolled you in.