Amazon Vendor Central: EDI vs API (2026)

Short answer

An Amazon vendor exchanges the same four business documents with Amazon whichever channel it uses: Amazon sends a purchase order, the vendor acknowledges it, announces the shipment, and invoices. There are three channels. You can key everything into Vendor Central by hand. You can use EDI, where structured files in X12 or EDIFACT format travel over a managed connection. Or you can use the vendor APIs in the Selling Partner API (SP-API), where your system pulls purchase orders and posts the replies as JSON over HTTPS.

EDI fits when your ERP or an EDI provider already speaks it and volume is high. The API fits when you have developers and no EDI stack, and it alone also reaches retail analytics, remittance detail and catalog data. Manual entry works until volume makes it the cause of late acknowledgements. A mix is fine as long as each document type has exactly one owner.

The API facts below come from Amazon's SP-API documentation, checked on 10 November 2026. One limit on this article: Amazon does not publish its EDI specifications on the open web. They sit behind the Vendor Central login, on what the SP-API docs call the EDI Resources help page. The transaction set names here are the X12 standard's own; which sets, versions and connection methods apply to your account, only that page can tell you.

The three channels

Vendor Central by hand. A person opens each purchase order, confirms quantities and dates, creates the shipment notice and types the invoice. Nothing to build. The cost is time and typing errors, and both grow with every purchase order.

EDI. Amazon and the vendor exchange files in a fixed format. X12 is the standard used in North America, EDIFACT the one common in Europe. Files move over a connection set up once and then left running; AS2 and SFTP are the methods usually named for Amazon, often through a value-added network or an EDI provider, but confirm what your account is offered in Vendor Central, because we could not read that list publicly.

SP-API. Amazon groups the vendor APIs into two families. Vendor Retail Procurement covers the classic model in which Amazon buys stock for its fulfillment centers: Vendor Orders, Vendor Shipments, Vendor Invoices and Vendor Transaction Status. Vendor Direct Fulfillment covers drop-ship orders that the vendor sends straight to the customer. Both are plain REST with OAuth tokens, and both are pull-based: nothing arrives unless you ask.

Document by document

The X12 names are from the standard's transaction set list at x12.org. The EDIFACT message names are the usual counterparts; we could not open the UN/EDIFACT directory today to re-check them, so treat those four names as common knowledge and not as a citation.

Purchase order. X12 850 (Purchase Order), EDIFACT ORDERS. In the API: getPurchaseOrders for a list filtered by date, state or vendor code, and getPurchaseOrder for one order with its lines, quantities and costs.
Purchase order change. X12 860 (Purchase Order Change Request, Buyer Initiated). The API has no separate change document. A changed order carries a purchaseOrderChangedDate, and you find changes by calling getPurchaseOrders with changedAfter and changedBefore, or with isPOChanged=true.
Acknowledgement. X12 855 (Purchase Order Acknowledgment), EDIFACT ORDRSP. In the API: submitAcknowledgement, with a code of accepted, backordered or rejected for every line.
Routing request and instructions. X12 753 and 754. The API counterpart is SubmitShipments to request a pickup and GetShipmentDetails to read the routing, available to vendors on Amazon-paid (collect) freight in North American and EU stores, for standard pallets only.
Advance ship notice. X12 856 (Ship Notice/Manifest), EDIFACT DESADV. In the API: SubmitShipmentConfirmations.
Invoice. X12 810 (Invoice), EDIFACT INVOIC. In the API: submitInvoices, which also carries credit notes in Europe.
Inventory. X12 846 (Inventory Inquiry/Advice). The retail procurement APIs have no inventory feed; the Direct Fulfillment family has its own Inventory API for drop-ship availability.
Remittance. X12 820 (Payment Order/Remittance Advice). On the API side Amazon now has a Finance Remittance API for vendors, version 2026-03-17, with getRemittanceHeaders and getRemittance. It returns what the Payments and Remittance view in Vendor Central shows: payments, deductions and the invoices each payment covers.
Technical receipt. X12 997 (Functional Acknowledgment). The API equivalent is the Vendor Transaction Status API, covered below.

What the API asks of you

Amazon's use case guides carry business rules that matter more than the endpoint list:

Acknowledge within 24 hours, backordered items included. The acknowledgement guide allows updates to quantity, price and dates for 48 hours; after that Amazon expects date changes only.
Acknowledge every line. Lines missing from the acknowledgement are treated as rejected, and a line first rejected cannot later be switched to accepted.
Send the unit cost, and make it match the invoice. Amazon's payment systems compare the two and may delay payment when they differ.
Poll for changes on a schedule. Amazon changes purchase orders after creation: windows, quantities, costs, destinations, cancellations. Its own example is calling four times a day for orders changed in the last six hours. You cannot change an order through the API yourself; that stays a manual step in Vendor Central.
Get the shipment confirmation in before the goods. The shipment confirmation guide says a missing or late confirmation results in chargebacks, that small parcel shipments need one per carton, and that a truckload should carry no more than 100 confirmations, ideally one.
Keep invoice numbers unique, never reuse one, never send a zero total, and use a remit-to address identical to the one Amazon has on file, or the invoice fails.

Region support is uneven. The orders and invoices operations are listed for North America, Europe and the Far East. SubmitShipments and GetShipmentDetails are listed for North America and Europe, and GetShipmentLabels for North America only. Check each operation's region line before you promise a workflow.

Asynchronous posts and the status API

Every post to these APIs is accepted first and processed later. The call returns a transaction ID, and the Vendor Transaction Status API tells you what became of it. Its semantics are unusual. For acknowledgements and invoices the only states are Processing and Failure, and a transaction still in Processing after 15 minutes is to be read as successful. An explicit Success state exists only for shipment confirmations and shipment requests in North America and Europe. If Vendor Central does not reflect the document within 30 minutes, Amazon's instruction is to open a support case with the transaction ID.

So store every transaction ID with its document, check it after 15 minutes, alert on Failure, and reconcile daily against Vendor Central for the first weeks.

What only the API reaches

EDI ends at the transactional documents. A vendor that registers for SP-API also gets data that never travelled over EDI:

retail analytics reports for sales, traffic, inventory, forecasting and net pure product margin, through the Reports API;
the vendor analytics dataset in Data Kiosk, which Amazon describes as more than 100 metrics across sales, traffic, inventory and forecast, queried with GraphQL at the granularity you choose;
Brand Analytics, coupon and promotion performance reports;
catalog and listing data, and A+ content;
remittance detail, through the Finance Remittance API above.

This is why vendors with working EDI still register an SP-API application: EDI moves documents, the API feeds reporting.

What EDI still does better

Push delivery. A purchase order arrives when Amazon issues it. The vendor use case directory lists no notification types for retail procurement, so the API side is polling.
ERP fit. Most ERP and distribution systems have EDI modules or partners that already map the purchase order, ship notice and invoice. Our SAP and SP-API article covers the other route.
One standard across retailers. If you already trade by EDI with other retailers, Amazon is one more trading partner on the same platform, not a new integration style.
Explicit change documents in place of a changed-since query you have to remember to run.

How to choose

You already run EDI with other retailers. Add Amazon as a trading partner, plus a small SP-API application for analytics and remittance.
You have developers, a modern ERP or a custom back office, and no EDI. Go API only. You avoid an EDI provider's fees and a second format to learn.
You ship drop-ship orders. Use the Direct Fulfillment APIs. Amazon's workflow guide notes that orders can also be confirmed by EDI or in Vendor Central, but labels, packing slips and the dynamic sandbox are in the API.
A handful of purchase orders a week. Stay manual and spend the budget elsewhere, but pull the analytics by API so nobody exports spreadsheets.
Several vendor codes or countries. Check early how your vendor groups map to applications; a private vendor application authorizes itself, and authorizing more vendor groups is possible only up to a limit.

Getting API access as a vendor

A vendor building for itself registers as a private developer from inside Vendor Central: Integration, then API Integration, then the developer profile, as the private vendor registration page describes. You state your use cases and security controls, pick roles, and Amazon opens a case; answer its questions within five days or the case closes. The retail procurement operations list the Amazon Fulfillment and Inventory and Order Tracking roles, neither of which is restricted. Direct Fulfillment is different, because those orders carry customer names and addresses: the Direct-to-Consumer Shipping role is restricted, comes with extra questions about data handling, and its order calls need a Restricted Data Token. A private application is then self-authorized, with no OAuth screens to build.

Migrating from EDI or manual to the API

List who owns each document today, per vendor code: manual, EDI or API. Gaps and double owners both show up here.
Start read-only. Pull purchase orders by API while the old channel keeps answering them, and compare what you receive for two weeks.
Move one document type at a time. Acknowledgements first, then shipment confirmations, then invoices. Agree each cut-over date with your Amazon contact so the same document is not sent on two channels afterwards.
Plan for invoice parallel testing. Amazon requires it before submitInvoices counts for payment: you send invoices both in Vendor Central and by API, on production purchase orders, until the content of at least three invoice files has been validated, and Accounts Payable emails you when you may stop.
Keep the old channel available for a month after the last cut-over.

Amazon's public pages describe the move from Vendor Central invoices to API invoices. They do not describe switching an EDI connection off, so ask in a Vendor Central support case how your EDI setup should be retired.

Testing

The retail procurement orders, shipments and invoices APIs have a static sandbox, which returns canned responses for fixed inputs. It proves your serialization and error handling and nothing about business rules. The transaction status API and the Direct Fulfillment APIs have a dynamic sandbox that keeps state, and Direct Fulfillment adds a test data API to generate order scenarios. Real validation therefore happens in production with a narrow scope: one vendor code and the first few purchase orders checked line by line in Vendor Central. Test the unhappy paths on purpose: a partial acknowledgement with a backorder, an order changed after acknowledgement, an invoice whose cost differs from the acknowledgement.

If you want the data, not the pipeline

Half of the reasons to touch the vendor APIs are about reporting, not documents. If that is your case, you may not need to build anything. DataDoe, the product our team engineers, connects to Vendor Central and keeps retail analytics, purchase orders, invoices and remittances as tables you can query from an AI client, the REST API or BigQuery. Its Amazon Vendor Central API page shows the coverage, and Amazon Vendor Central reports walks through the reports themselves. Document exchange with Amazon, the subject of this article, stays with your EDI or API integration.

How we run a vendor integration

Deltologic has worked with SP-API since 2020. A vendor project starts with the ownership list from the migration section and the chargeback history, which says which document is hurting today. We build the purchase order sync and status tracking first, then add documents in the order above. Our marketplace integrations and API migrations pages describe the service, and the Amazon and NetSuite integration guide shows the ERP side. To talk through EDI, API or a mix for your account, get in touch and tell us which ERP you run and how many purchase orders you see in a week.

Frequently asked questions

Does Amazon Vendor Central require EDI?

No. A vendor can work manually in Vendor Central, exchange documents by EDI, or use the vendor APIs in the Selling Partner API. All three carry the same purchase orders, acknowledgements, shipment notices and invoices, and many vendors combine them.

Which EDI documents map to the Amazon vendor APIs?

The purchase order (X12 850) maps to getPurchaseOrders, the acknowledgement (855) to submitAcknowledgement, the advance ship notice (856) to SubmitShipmentConfirmations and the invoice (810) to submitInvoices. Amazon keeps its own EDI specifications inside Vendor Central, so confirm the exact document set for your account there.

How fast must a vendor acknowledge an Amazon purchase order?

Amazon's SP-API documentation says to submit the acknowledgement within 24 hours, backordered items included. Changes to quantity, price and dates can be sent for 48 hours; after that Amazon expects only ship or delivery date updates.

Can I use EDI and the Amazon vendor API at the same time?

Yes, as long as each document type has one owner. A common split is EDI for purchase orders, ship notices and invoices, and an SP-API application for retail analytics reports, Data Kiosk and remittance data, which EDI does not carry.