Amazon Shuts EDI Door on New Direct Fulfillment Vendors

Amazon has quietly closed the door on EDI for new Direct Fulfillment vendors. Multiple 2026 vendor-integration guides now confirm the same thing: if you're setting up a new Amazon Vendor Central Direct Fulfillment (dropship) connection today, Amazon pushes you onto the Selling Partner API instead of EDI. For anyone running an Amazon Amazon Direct Fulfillment EDI program alongside core 1P wholesale, this isn't a footnote. It's a second integration stack you now have to build and maintain, permanently, for one trading partner.

What Amazon changed for Direct Fulfillment vendors

For new Vendor Central Direct Fulfillment setups, Amazon now onboards through SP-API rather than EDI. As one 2026 guide puts it plainly: Amazon's 1P relationship (Vendor Central, invitation-only) runs on EDI for core wholesale documents, while Direct Fulfillment (dropship) increasingly uses SP-API for new integrations. The same source is explicit that SP-API (REST) is used for Direct Fulfillment and complementary data; new Direct Fulfillment integrations are API-first, while 1P wholesale (850/856/810/855) remains EDI.

If you already run an EDI-based Direct Fulfillment connection, nothing forces you off it yet. As that same FAQ notes, Direct Fulfillment (dropship) now uses SP-API for new integrations, though existing EDI Direct Fulfillment continues. This is about new onboarding, not a mandated rip-and-replace. Yet.

What's staying on EDI: don't touch this

The core wholesale document set is untouched and non-negotiable. Amazon Vendor Central EDI uses five mandatory ANSI X12 documents: 850 (PO), 855 (PO Acknowledgment), 856 (ASN), 810 (Invoice), 846 (Inventory). One analysis is direct about the limits of SP-API's reach here: Amazon's SP-API for vendors handles Direct Fulfillment workflows and increasingly covers reporting and listing data, but wholesale purchase orders, invoices, and ship notices still run on EDI for the vast majority of Vendor programs. Amazon has given no timeline for changing this.

Why this is happening now

Amazon's investment signal is unmistakable. Third-party developers will face an annual subscription fee of $1,400 starting January 31, 2026, plus monthly usage fees based on GET API call volume beginning April 30, 2026. That's not a sign of a platform deprioritizing its API layer, it's the opposite: Amazon is monetizing SP-API because volume through it keeps growing. One guide ties the two facts together directly, noting the Selling Partner API continues to expand, with a new paid subscription model for third-party developers effective January 31, 2026, and Amazon has not announced any end-of-life date for EDI, but the direction is clear: tighter enforcement, faster expectations, and growing API capabilities alongside traditional EDI.

One trading partner, two protocols

This is the part that breaks most onboarding playbooks. A vendor running 1P wholesale and Direct Fulfillment under the same Amazon account now needs an AS2/SFTP EDI connection for POs, invoices, and ASNs, plus an OAuth/REST developer setup for DF orders and shipping confirmations. The "one trading partner, one connection method" assumption doesn't hold anymore for Amazon, and the fix isn't to pick a side. One integration consultancy frames it correctly: SP-API is expanding but EDI is still non-negotiable for most Vendor Central programs. The smart answer in 2026 is a dual-integration strategy, not a migration.

On the cost side, SP-API setups skip the VAN or per-kilocharacter fees traditional EDI carries, since purchase orders, acknowledgements, shipping labels, Advance Ship Notices, and invoices all flow automatically, with no EDI VAN subscription required on the SP-API path. Whether that nets out cheaper once you factor in the new $1,400 developer fee and GET call overages depends on your transaction volume, but it's worth running the math with your EDI provider rather than assuming.

It doesn't stop at the Amazon connection

Once DF orders and ship confirmations are flowing, whether through EDI or SP-API, you still have to generate labels and manifest with actual carriers for direct-to-consumer parcels. Amazon's own tooling covers part of this: the SP-API workflow lets you get the shipping label for the order by using the createShippingLabel operation, a synchronous operation that creates and then returns the shipping labels for a purchase order, but note it also rejects partial requests since partial shipping label requests are rejected, direct fulfillment does not allow partial fulfillment. Everything downstream of that, rate shopping across non-Amazon carriers, exception handling, multi-carrier visibility, is where tools like Cargoson, ShipStation, Shippo, and EasyPost come in. That's a separate integration decision DF-heavy vendors need to make once the Amazon order feed itself is sorted.

What EDI leads should do now

1. Audit which Amazon relationship types you run: 1P wholesale, legacy DF-via-EDI, or new DF onboarding.
2. Confirm with your EDI provider or integration team whether SP-API support already exists or needs building from scratch.
3. Don't plan to sunset EDI for wholesale. Budget for dual maintenance instead, indefinitely.
4. If you're onboarding a new Direct Fulfillment relationship, build the SP-API path from day one. Requesting an EDI exception isn't an option Amazon is offering anymore.

Bottom line: new Direct Fulfillment setups require SP-API, effective now. There's no published deadline for migrating existing EDI-based wholesale or legacy DF connections, but there's also no sign Amazon is walking this back.