Amazon Vendor Central EDI: Set It Up or Use the API

Amazon Vendor Central EDI (electronic data interchange) is the standardized exchange of purchase orders (POs), acknowledgements, advance shipment notifications (ASNs) and invoices between a vendor and Amazon, and it is optional. The Selling Partner API (SP-API) runs those steps instead of EDI or beside it. For Retail, Amazon's options table lists no API option for item cost or inventory feeds.

An IT lead at a brand that sells to Amazon as a vendor asked me for a yes or no: "Do we need EDI for Vendor Central, or can the API handle our purchase orders, ASNs and invoices?" Amazon answers it one business process at a time, and so does this plan.

The acknowledgement is where the choice carries risk. On the API, Amazon implicitly rejects any line an acknowledgement leaves out, and a line first rejected can't be updated to accepted. The team's rule records which ASINs it is discontinuing and which it only backorders. So the acknowledgement that reaches Amazon lists every line and marks only the discontinued ASINs Rejected: the agent drafts it from the live PO, and a planner approves it first.

Amazon's options table puts purchase orders, ASNs and invoices on both routes, and keeps item cost and inventory feeds off the API

Amazon's "EDI and API options per business type" table answers the question process by process, with columns for the Vendor Central portal, EDI and the API (application programming interface). The Retail rows, with the Vendor Central MCP tool for each API row:

Amazon's "Automation at Amazon" page sets the frame: EDI and the API are two automation options for Retail and Direct Fulfillment (DF) vendors, chosen by your system capabilities. They can run in parallel, with the portal kept for manual work during connectivity issues, and vendors without in-house systems can hire a third-party service.

Marking items temporarily unavailable is portal and EDI only, with no API. In the other direction, four rows have no EDI option: PO status, PO confirmation status, shipment confirmation status and sales data reports. Sales data moved to the API when Amazon stopped publishing the X12 852 and 830 Amazon Retail Analytics (ARA) feeds after June 30, 2022, which the ARA warehouse guide covers.

Amazon Agent Atlas holds both tables and the Automation at Amazon page, so the agent cites Amazon's own table when it says which route a process allows.

A Vendor Central EDI connection runs over AS2, SFTP or a VAN and passes Amazon's message tests before production

A Vendor Central EDI connection is self-serve: Amazon's "EDI Integration overview" says you run the full integration cycle on your own timeline, without contacting Amazon. It accepts X12, a standard EDI format used mainly in North America, and EDIFACT, used mainly by Retail vendors in EMEA (Europe, the Middle East and Africa) and also in Australia and Brazil. Direct Fulfillment adds XML.

Setup runs in three sections under the Integration (EDI/API) tab:

1. Home. Click Start EDI for a parent vendor code; Retail child codes inherit its settings. Set up a new connection, or reuse one from another EDI-enabled vendor account.
2. Messages dashboard. Complete Global settings and promote every setting to test or production by hand, or it can't exchange messages. Then test each message type and schedule it for production, in any order. Not all are mandatory.
3. Connection dashboard. Add a test or production connection over AS2 (Applicability Statement 2), Amazon's hosted SFTP (Secure File Transfer Protocol) or a VAN (Value Added Network) provider, and pass the receiving and sending connectivity tests.

Every transmission must carry all the required data elements in Amazon's EDI specifications, and each message must pass tests of its structure and content. The specification packages, with mapping guides and sample files, are on the Resources page in Vendor Central. For Retail X12 they cover the 850, 855, 860, 856, 810, 846, 820, 753, 754, 824 and 997. Three limits apply:

• Invoices. EDI invoices are for Retail accounts only, not Amazon Advantage vendor codes.
• Remittance advice. Only Retail vendors in North America receive it, as the X12 820.
• Functional acknowledgement (FA). Amazon generates it, as the X12 997. Its Direct Fulfillment page says vendors need not send one.

The EDI route needs an EDI system, or a third-party provider if you have none in-house. Amazon's Resources page lists EDI service providers, and its hosted SFTP server is free of charge for file transfer. Once live, Operational Analytics tracks each transmission and its validation and processing failures.

The Selling Partner API route starts with an authorized app, and Amazon processes each submission asynchronously

The Selling Partner API route starts in the same Integration tab, under API Integration. Amazon's API Integration Overview lists five stages:

1. Developer registration. Register a developer profile.
2. App authorization. Authorize the app and download its credentials.
3. App development. Build the app, or use a third-party developer.
4. Testing. Test the app and its calls in Amazon's sandbox.
5. Production. Move the integration live.

Roles decide which operations an app can call: Amazon's Vendor Orders reference lists Amazon Fulfillment or Inventory and Order Tracking for reading and acknowledging orders. Direct Fulfillment needs an additional set of roles. Amazon's restricted roles contain personally identifiable information, and restricted Direct Fulfillment operations take a Restricted Data Token.

On Kuudo, the Vendor Central MCP carries the vendor order, shipment, invoice and transaction operations, and the Selling Partner MCP carries the shared SP-API resources, Finance Remittance among them. You authorize your own Vendor Central account, and the operations are already tools your AI calls: through Kuudo's managed, verified SP-API app on Pro and Scale, with no app registration, or your own app on Community.

Writes on this route are asynchronous. POST operations such as submitAcknowledgement and submitShipmentConfirmations return a transaction ID, and Amazon reports the final status through getTransaction for Retail or getTransactionStatus for Direct Fulfillment. A valid transmission doesn't always meet Amazon's vendor performance policies, so chargebacks can still apply.

For Retail, both routes face the same deadlines: confirm each PO within 24 hours and send the ASN before the shipment arrives

Amazon's order deadlines don't change with the route. Its "Confirm purchase orders" page says you must confirm or reject every PO within 24 hours of the order being placed, and confirming commits you to the assigned shipping window. On EDI, the page lists the ORDRSP/855 segments: QTY+12 to confirm, QTY+185 for temporarily out of stock and QTY+182 for no longer available.

For an item you no longer supply, two consecutive rejection codes at least 48 hours apart stop Amazon ordering those ASINs from your vendor code. On the API, submitAcknowledgement adds its own rules:

• Every line. Amazon implicitly rejects any line left out, and rejects an acknowledgement with no code (Accepted, Backordered or Rejected).
• Cost. The unit cost must match the invoiced unit cost, or payment may be delayed.
• Quantity. Lower than the PO is allowed; higher is not.
• Changes. A quantity, price or date change needs an updated acknowledgement within 48 hours. After that, Amazon expects only ship and delivery date updates.

An ASN is required for every shipment, regardless of size or payment terms, and must reach Amazon before the shipment arrives at the fulfillment center, one ASN per truckload. EDI vendors edit an ASN only through EDI, resending it whole with the BSN "05" replacement qualifier. On the API, you can replace an earlier shipment confirmation with an updated one.

A missing, inaccurate or late ASN triggers the ASN accuracy chargeback, and the vendor chargeback rules cover the rest. Amazon's API invoice rules add unique invoice numbers that are never reused, payment terms that match the buyer's, and a remit-to address that matches Amazon's records.

Amazon Agent Atlas returns these rules from "Confirm purchase orders" and "Advance shipment notification". vpo_getPurchaseOrdersStatus returns each item's acknowledgement history and received quantity, so the agent checks a draft against what Amazon already holds.

The Vendor Central MCP runs the API route from an AI client, and a person approves each acknowledgement, ASN and invoice

The Vendor Central MCP is a Model Context Protocol (MCP) server: the vendor operations become tools an agent calls from the AI client a team already uses. A Retail order runs in five steps:

1. Read. vpo_getPurchaseOrders lists POs created or changed in a time window, and vpo_getPurchaseOrder returns their lines, quantities and cost.
2. Draft. The agent checks each line against the team's rule and Amazon's, then drafts vpo_submitAcknowledgement with a code for every line.
3. Approve. A planner approves the draft before it reaches Amazon, which returns a transaction ID for vts_getTransaction to read.
4. Route. Collect (WePay) vendors in North America and the EU request a pickup of standard pallets with vshp_SubmitShipments and get routing instructions from vshp_GetShipmentDetails. Unconfirmed POs make the request fail.
5. Ship and bill. vshp_SubmitShipmentConfirmations sends the ASN and vinv_submitInvoices the invoice, each approved the same way.

Direct Fulfillment follows the same pattern, with tools for orders, shipping labels, shipment confirmations, inventory, invoices and transaction status; for orders, shipping and transaction status, the Vendor Central MCP carries Amazon's current 2021-12-28 versions. Amazon's table lists no API for Retail item cost or inventory sharing, and the MCP has no tool for them. Remittance is the exception: the Selling Partner MCP's remittance read lets the agent see what Amazon paid and deducted per invoice.

Every write tool applies workspace policy, which can require a person's approval (how write tools work), and this team's policy requires it for every acknowledgement, ASN and invoice. For the daily run, Amazon Agent Flow schedules each status check, and the close-out lists every send with what Amazon reported:

What happens next: move PO acknowledgements to the API first and invoices last

The plan sends each process to the route Amazon allows, in the order its clocks reward:

1. Keep item cost and inventory feeds on EDI or the portal. Amazon's table lists no API for them. Remittance advice can move to the Finance Remittance API whenever the team is ready.
2. Run Direct Fulfillment on the API, Amazon's recommended method. The policy's two-hour window is the same on EDI.
3. Move Retail acknowledgements first. The 24-hour clock and line-level rules reward a checked, approved draft, while EDI carries everything else in parallel.
4. Move ASNs next. Each must reach Amazon before the shipment does.
5. Move invoices last. Either route starts them in parallel testing with Accounts Payable.

Save the team's confirmation rule as its own Skill; no published Kuudo Skill covers vendor order exchange. When the team discontinues an ASIN, the same agent can read its campaigns through the Amazon Ads MCP, because an ASIN Amazon stops ordering can still be buying ad traffic.

The pattern is one route per process: Amazon's pages decide what can move, the agent drafts, a person approves, and Amazon's status confirms.

Next: how to prevent Amazon vendor chargebacks, the clocks and thresholds a late acknowledgement or a missing ASN runs into.