EDI or API: How Amazon Vendors Connect Today

Amazon runs two separate programs for anyone selling through the platform. Vendor Central is the wholesale side: Amazon buys inventory through purchase orders and resells it as the retailer, so vendors deal with Amazon itself rather than the end shopper, and the listing shows up to customers as “Shipped and Sold by Amazon.” Seller Central is the marketplace side, where sellers list and sell directly to shoppers. Vendor itself splits into two flows: so-called “Retail”, where Amazon takes possession of stock into its own Fulfilment Centers, and “Direct Fulfilment” (DF), essentially Amazon’s version of dropship, where Amazon takes the order but the vendor ships it from their own warehouse. Everything below applies to vendors running either flow, since both connect through the same purchase order, shipment, and invoicing cycle.

For most of the time Vendor Central has existed, ‘EDI’ was the only way to connect electronically with Amazon as a wholesale supplier, what Amazon itself still calls “electronic integration”. Amazon’s Selling Partner API (SP-API) only started opening up to Vendor accounts specifically, rather than staying limited to Seller Central, roughly two to three years ago. Plenty of vendor ops teams still don’t realise API is an option for them at all. EDI was set up years ago, it works, and nobody had a reason to go looking for an alternative. Companies with no EDI framework already in place, or unwilling to absorb the steep upfront cost of building one, often just skipped a direct Vendor Central relationship altogether and sold to Amazon some other way.

EDI itself predates Amazon by decades

Large manufacturers and distributors have run it with retail trading partners since long before Amazon was a channel worth connecting to, and the infrastructure and the expectation that a supplier would have it were already in place by the time Vendor Central existed, so EDI became the default there too. Even those long-established EDI marketplaces are now adding API alongside it, drawn by the same flexibility that makes API attractive to mid-size vendors and to anyone who doesn’t want to stand up the dedicated middleware, translation software, and Value-Added Network that EDI has traditionally required just to get started. That flexibility goes beyond setup cost, too: a marketplace can build ad hoc APIs for whatever specific data point it needs next, reports, advertising modules, real-time data exchange, in a way the rigid, fixed-format EDI framework was never built to support.

For a lot of wholesale operations, EDI still works and still matters, and nothing here is an argument for ripping it out overnight. Below is what’s actually different between the two, and why API is now a real option for vendors, not just a Seller-only technicality. Ten minutes well spent if you’re the one who owns how your operation talks to Amazon.

What EDI Is, and Why It’s Worked Well Until Now

EDI, short for Electronic Data Interchange, means exchanging standard business documents, purchase orders, invoices, shipping notices, as structured, machine-readable messages instead of PDFs, emails, or phone calls. Two parallel standards define what those messages actually look like: X12, set by a US ANSI-accredited committee, and EDIFACT, the UN-governed version used more widely outside the US. Amazon’s Vendor cycle runs on five of these documents, and both naming conventions show up depending on who you ask, so it’s worth knowing both:

• 850 (X12) / ORDERS (EDIFACT): Purchase Order
• 855 / ORDRSP: Order Acknowledgment
• 856 / DESADV: Advance Ship Notice (ASN)
• 810 / INVOIC: Invoice
• 846: Inventory Update

The format of each one is fixed by the standard itself, not something a vendor or Amazon adjusts case by case, and that fixed structure is exactly what has kept these documents working reliably, unchanged in shape, across thousands of vendors for years. It’s Vendor-only, too: Seller accounts, Buy Shipping, and other logistics programs sit outside EDI’s scope and need API access regardless.

That fixed format comes with a price tag on implementation, too. Getting EDI working means dedicated middleware, translation software, and mapping every field to Amazon’s message specifications, often with a Value-Added Network (VAN), a third-party service that receives, translates, and forwards EDI messages between trading partners, sitting between you and Amazon as well. Setup time follows the same order: fastest through a modern integration platform, slower through a traditional VAN, slowest building it in-house. That’s not an in-house problem specifically, it’s the nature of any complex integration: several layers to combine (ERP, middleware, translation software, field mappings) and just as many systems that don’t speak the same language, all before certification testing against Amazon’s message specifications can even begin. A modern platform absorbs most of that work for you, a VAN absorbs some of it, and building in-house means doing all of it yourself. 

That same rigidity carries into how the integration runs day to day, on two fronts.

• Timing. Amazon holds fixed deadlines no matter which connection method you’re on: an 855 (ORDRSP in EDIFACT) acknowledgment within 48 hours of the 850 (ORDERS) purchase order, an 810 (INVOIC) invoice within 24 hours of shipment confirmation, and the 856 (DESADV) ASN before the shipment physically reaches the fulfillment center. On EDI, translation and VAN hops eat into that fixed window before your team even sees the document, leaving less margin than the deadline itself suggests.
• Content. Garbage in, garbage out: the message has to validate cleanly on both ends, and if a product’s identifiers don’t match between the vendor’s system and Amazon’s, it gets rejected outright, at receiving, at order acknowledgment, wherever the mismatch shows up first. 

Miss those windows, or send data Amazon flags as incorrect, and it shows up as chargebacks. Vendors also usually key their catalog to EAN or GTIN identifiers rather than Amazon’s own ASINs, and when those two identifiers drift out of sync (a product gets renamed, discontinued, or relisted, or the ASIN is set up wrong for how the item actually ships, inner pack quantity, case pack, bundle contents, and so on), the result is rejected orders, ASN mismatches, and invoice disputes. For vendors who aren’t watching compliance closely, chargeback-driven deductions add up over a year. Unconfirmed PO chargebacks and non-compliant ASNs tend to be the two biggest contributors, and the penalty typically scales with how late or inaccurate the notice was.

What SP-API Changes

You’ll still find integration guides that describe this as a hard line: EDI for Vendor Central, API for Seller Central, tied to the wholesale-versus-marketplace business model. That described things accurately a few years ago, before Amazon published dedicated Vendor endpoints inside SP-API itself, covering orders, shipments, and invoicing. Amazon’s own developer documentation for vendors puts both connection methods at the same level of automation for core operational processes, with the API adding reach into reports, listings, and marketing that EDI was never built to touch. Vendors aren’t required to pick one, and plenty run both at once for different parts of the business.

SP-API works differently in a few concrete ways:

• Scope. Where EDI covers supply chain documents, SP-API also reaches listings, reporting, advertising, and A+ content. One integration technology can now cover both the transactional side and the catalog/marketing side of a vendor account, and it extends to Seller and Fulfillment programs too, not just Vendor.
• Format and speed. Instead of fixed X12/EDIFACT documents moving through translation layers, SP-API uses standard REST calls: GET to query, POST to submit. Payloads are lighter and there’s no VAN or middleware layer required to translate between formats, which is where a lot of the delay in EDI flows actually comes from.
• Catalog matching. This is the one that matters most for reducing chargebacks. EDI messages can technically carry an ASIN field too, but the ERPs and middleware most companies have mapped to EDI usually don’t flex that far. Their rigid framework tends to key everything to EAN or GTIN exclusively, so the ASIN link never gets captured in the first place. API-based systems, an omnichannel platform like Base included, are built with more room to pull in both. SP-API itself returns and accepts both ASIN and external identifiers (EAN, GTIN) on the same call, so a system built on it can pull a live snapshot of what’s actually listed under a vendor’s Amazon catalog and reconcile it against other channels, rather than relying on a static EAN/GTIN mapping that quietly goes stale.

SP-API still doesn’t have full parity, though. A handful of programs still require EDI. WePay/Collect, Amazon’s freight-collect logistics model, runs on routing-specific documents (the X12 753/754 pair, or IFTMBF/IFTMIN in EDIFACT) that carry pickup location, exact warehouse address, weight, pallet counts, and AMZNCC labels, a level of shipping detail SP-API doesn’t fully expose yet – but just one of the options alongside SSCC labels.

EDI vs SP-API at a Glance

Why This Is More Than a Technical Detail

For a vendor ops team, the EDI-to-API shift shows up as a few very concrete outcomes:

• Potentially fewer chargebacks tied to catalog mismatches, since ASIN-based matching removes one of the more common sources of rejected POs and ASN discrepancies.
• Generally faster order confirmation and acknowledgment cycles, since there’s no translation layer sitting between the vendor’s system and Amazon’s.
• Lower cost to add new Amazon programs. Once an operation is integrated via API, extending into Seller, FBA, or MCF doesn’t mean standing up a second, separate integration project. It’s the same technology doing more.
• No ongoing VAN fees or dedicated EDI middleware to maintain, which is often the least visible but most persistent cost of an EDI setup. With that overhead gone, the omnichannel platform and the ERP sitting on top can spend their effort on the parts that actually add value, automation, reporting, cross-channel logic, rather than mostly mapping fields between formats.

Base already runs Amazon Vendor integrations on SP-API, and works with Amazon across several of its other programs too. Automated Actions let a vendor customize exactly how orders, shipments, and invoices move once they’re in Base, tuned to their own workflow instead of a fixed message format. The lower implementation cost that comes with API goes toward that kind of tailoring, connecting the integration to the rest of a vendor’s stack, warehouse, storefronts, other marketplace listing catalogs, rather than toward mapping and translating fields the way an EDI setup demands. Once a catalog is synced this way, it sits alongside 1,700-plus other plug-and-play integrations for marketplaces, ERPs, and carriers, so adding a new Amazon program later doesn’t mean starting an integration project from zero.

Where to Go Next

If you’re evaluating how your Amazon Vendor account connects, whether it’s still on EDI, already on API, or some mix of both, it’s worth seeing what a fully API-based setup actually looks like in practice: Amazon Vendor integration covers how PO, ASN, and invoicing flows work end to end for Vendor Retail, and Amazon Direct Fulfillment integration covers the same for Direct Fulfillment orders, from PO to shipment to invoice. For the setup itself, the Amazon Vendor integration configuration guide walks through the actual configuration steps and feature setup, and Amazon Vendor Central with Base.com covers running listings, inventory, and orders from one dashboard once it’s connected. 

FAQ

Does this mean I should drop EDI right now? 

Not necessarily. If EDI is running reliably and your team has processes built around it, there’s no urgency to rip it out. The point is understanding that API-based integration now covers more ground than it used to and covers different use cases in specific areas, so it’s worth evaluating for expanding to new programs or when you’re troubleshooting recurring EDI-related issues.

Will Amazon eventually require API over EDI for vendors – or the other way round? 

There’s no announced deadline or public plan mentioning so, and most established vendor operations still run on EDI without issue. API covers more of the vendor lifecycle, but nobody’s forcing a migration.

Does switching to API mean re-mapping my whole catalog? 

It shouldn’t. A properly built API integration reconciles ASIN and external identifiers rather than replacing one with the other, so existing EAN/GTIN-based catalog data doesn’t need to be thrown out.

Can I run EDI and API side by side? 

Yes, and many vendors effectively do during a transition period or make them work in parallel for different use cases, since EDI and API cover overlapping but not identical ground.

What does getting SP-API access actually involve? 

Amazon’s own path is a handful of steps: register as a developer in Vendor Central, register the application, authorize it against your account, run it through sandbox testing, then move to production. Exchange of APIs including customers’ personal data includes a more detailed vetting process on vendors’ security posture, which is handled by your third-party developer company (such as Base) if you use one.