EDI vs SP-API for Amazon Vendor Central: document by document, cost by cost
For most of Vendor Central's history, being an Amazon vendor meant buying EDI: a provider or VAN, per-document or per-kilocharacter fees, mapping projects, and a monthly bill that scaled with your PO volume. Amazon's Vendor Retail Procurement APIs, part of the Selling Partner API, now cover the same exchange (purchase orders, acknowledgments, shipment notices, invoices, inventory, routing) with no per-document cost and JSON instead of X12. This page maps each EDI document to its API equivalent, compares what each path costs and requires, and lays out when EDI still makes sense.
getTransactionStatus (Vendor Transaction Status API)
Amazon to vendor
The business rules do not change with the transport. Twenty-four hours to acknowledge, complete acknowledgments, ASN before arrival, invoice cost matching the acknowledgment: Amazon enforces the same requirements whether the document arrived as X12 or JSON. What changes is who you pay to move it and how fast you can build and change the integration.
Cost
Where the EDI bill comes from, and what SP-API charges
Cost line
EDI
SP-API
Network transport
VAN or AS2 provider fees, often per kilocharacter or per document
HTTPS; no transport fee
Provider subscription
Monthly platform fee from the EDI provider, tiered by volume
None from Amazon
Setup and mapping
Mapping and testing per document type, per trading partner
App authorization in Vendor Central; roles granted once
Changes
Re-mapping when Amazon or your ERP changes a field
Code or configuration change on your side or your integrator’s
Scale
Bill rises with PO count and document size
Flat
For a vendor doing hundreds of POs a month, the EDI line is a real recurring cost that SP-API removes entirely. For a vendor doing ten, the bigger saving is usually time: an SP-API connection is authorized in an afternoon and changed in code, where an EDI change is a mapping ticket.
When EDI still wins
Three situations where X12 is the right answer
EDI is not obsolete. If your 3PL or warehouse system only exchanges X12 and it is the party that builds ASNs and labels, keeping Amazon on EDI avoids a translation layer. If you supply a dozen retailers who all require EDI, one more trading partner on an existing VAN is cheap and consistent. And if a legacy ERP already speaks 850/855/856/810 to other partners, adding Amazon as another EDI partner may be less work than a parallel API integration. Several vendors run both: SP-API for the PO and acknowledgment side, EDI where the warehouse needs it.
If you...
Lean toward
Pay a monthly EDI bill only because Amazon required it
SP-API
Confirm POs by hand in Vendor Central today
SP-API with rule-based acknowledgment
Run a 3PL that only speaks X12 and owns your ASNs
EDI for shipments, SP-API acceptable for POs and invoices
Supply many retailers on one VAN with an EDI team in place
EDI, unless the Amazon volume alone justifies the change
Are a new vendor with no EDI in place
SP-API; do not buy EDI to start
How InfiPlex connects
SP-API by default, EDI where a vendor needs it
InfiPlex is an Amazon-approved SP-API application. A Vendor Central Retail connection is authorized in Vendor Central, POs pull through the Vendor Orders API, acknowledgments go back through submitAcknowledgement from per-SKU rules, invoices post per PO through the Vendor Invoices API, and every submission's transaction status is tracked, with no VAN, provider, or per-document fee anywhere in the path. Vendors whose warehouse or ERP requires EDI can run that leg on EDI alongside. The program page is the Vendor Central Retail integration; the connection steps are on the retail SP-API set-up article.
Frequently asked
Questions, answered
The questions vendors ask when the EDI renewal lands.
No. Amazon's Vendor Retail Procurement APIs cover purchase orders, acknowledgments, shipment notices, invoices, inventory, and routing. Amazon accepts either EDI or the API, and you can confirm POs in Vendor Central itself as a fallback.
Amazon charges nothing for the Selling Partner API. There is no VAN, no per-document or per-kilocharacter fee, and no mapping charge from Amazon. Your cost is the integration itself, built in house or through an integrator like InfiPlex.
getPurchaseOrders replaces the 850, submitAcknowledgement the 855, submitShipmentConfirmations the 856, and submitInvoices the 810. Routing (753/754) maps to the Vendor Shipments API, inventory (846) to vendor inventory submissions, and the 997 to the Vendor Transaction Status API.
No. The 24-hour acknowledgment, complete line coverage, ASN before arrival, and invoice cost matching are enforced the same way regardless of transport. Chargebacks do not care whether the document was X12 or JSON.
When a 3PL that only speaks X12 owns your ASNs and labels, when you already run many retailers on one VAN with an EDI team, or when a legacy ERP already trades 850/855/856/810 with other partners. Some vendors run SP-API for POs and invoices and EDI for shipments.
Yes. Authorize the API connection in Vendor Central, run it in parallel on new POs while the EDI channel drains, and retire EDI once acknowledgments, ASNs, and invoices are flowing through the API. The PO data is the same on both sides.
InfiPlex connects Vendor Central Retail through SP-API by default, with no EDI fees. Vendors whose warehouse or ERP requires EDI can run that leg alongside the API connection.
Authorization in Vendor Central takes minutes once the roles are granted; most vendors are live in InfiPlex in one to three business days, with the remaining time spent on SKU confirmation rules and ERP mapping rather than on the connection.
Tell us your monthly PO count and what you pay today; we will tell you what the same exchange looks like on SP-API. Contact us, email info@infiplex.com, or call 888‑770‑0857.
Our website uses cookies to help provide the best user experience. By continuing to use this site, you consent to the use of cookies as described in our Privacy Policy. OK