Both routes move the same Amazon vendor documents. EDI sends them as files through a translator and a network; the Selling Partner API connects your own system to Amazon directly. The choice comes down to who owns the field mapping, how cost behaves as volume grows, and what your vendor agreement obliges you to use.
The documents are the same either way
Whichever route you choose, the traffic is identical. A purchase order arrives. You acknowledge it, saying what you will ship and when. You send an advance shipment notice before the goods arrive. You invoice. Remittance advice and chargebacks come back. Direct fulfilment orders, if you do them, run alongside. Catalogue and cost alignment sits underneath all of it.
That matters because people talk about EDI and API as if they were different business processes. They are not. They are two ways of carrying the same conversation, and the operational difficulty of being an Amazon vendor — windows, accuracy, timing — is the same in both. Our Amazon Vendor Central Odoo integration page sets out that document flow in detail if you want the shape of it first.
So the decision is not about capability in the abstract. It is about where the mapping lives, who maintains it, how you are charged, and what your own agreement with Amazon requires. If you are still working out whether you are a vendor or a seller at all, the Amazon Odoo integration guide separates Seller Central from Vendor Central before anything else.
What EDI actually is, in plain language
EDI is two things that get spoken about as one. First, a file format: a standard way of writing a purchase order or an invoice as a structured document, with agreed segments and codes. Second, a delivery network — traditionally a value-added network, a VAN, that sits in the middle and carries files between trading partners.
Between your system and that format sits a translator, which maps your fields onto the standard ones. Someone owns that map. It is usually the EDI provider, configured during onboarding, and it is the reason EDI projects feel front-loaded: most of the work is agreeing what maps to what, and most of the ongoing cost is per document or per kilocharacter through the network.
None of this is obsolete or inferior. It is how a great deal of retail trade still runs, it is well understood, and if you already trade EDI with several large retailers it is infrastructure you have paid for and know how to operate.
What an API integration does differently
Amazon exposes vendor documents through its Selling Partner API. An API integration talks to those endpoints directly from your own system, on your own credentials, with no network in the middle and no translation layer. The map still exists — something has to decide which of your fields becomes which Amazon field — but it lives inside your own integration rather than inside a third party’s configuration.
The practical consequence people notice first is that there are no per-document fees, because there is no intermediary charging for carriage. The consequence that matters more over a year is that validation can happen before submission, inside your ERP, where the person who can fix the problem is sitting.
The five differences that actually decide it
Who owns the field mapping
With EDI the map typically sits with your provider, which means changes go through a ticket and a change window. With a direct integration it sits with you or with whoever built it, which means changes are faster and also that you are responsible for them. Neither is better in the abstract. It depends entirely on whether you would rather wait or own it.
How the cost behaves as you grow
Per-document pricing is predictable and it scales linearly with your success. A direct connection moves the cost into build and maintenance, which is lumpy at the start and then flat. At low volume EDI is often cheaper in total. At high volume the arithmetic usually reverses. Work out your own crossover rather than taking anyone’s word for where it sits, including ours.
Where validation happens
This is the difference that shows up in chargebacks. If Amazon’s rules — acceptance and ship windows, the notice arriving before the delivery, label and invoice references — are checked inside your ERP before anything is sent, defects get prevented. If they are checked after translation, or not at all until Amazon rejects the document, they get discovered. The ASN chargeback post goes into why that one is a sequencing problem rather than a warehouse one.
What happens when Amazon changes something
Amazon changes requirements. With a provider in the middle, those changes are the provider’s job, which is genuinely valuable — you may not hear about a change at all. With a direct integration, somebody has to watch for them. That is an argument for EDI that does not get made often enough, and it is a real one if you have no technical owner internally.
What your vendor agreement requires
This can settle the question before the other four get a hearing. Vendor agreements differ, and some mandate particular documents through particular channels. Read yours, and ask Amazon directly which documents each route covers for your programme and region rather than assuming. Everything in a comparison like this is advice; your agreement is an obligation.
Not sure which documents your agreement actually mandates?
Send us the document list from your vendor agreement and your current setup. We will tell you what each route covers, what it does not, and which questions to put to Amazon before you commit.
Talk to Us About Vendor CentralWhen EDI is the right answer
We build the API route, so take this in that light — but there are cases where we would tell you to stay on EDI, and we have.
If your agreement mandates EDI for documents you cannot avoid, the decision is made. If you already run EDI with four other large retailers, adding Amazon as a fifth lane in a system your team operates daily is usually cheaper and calmer than standing up a separate direct connection for one partner. If you have no technical owner and no appetite to acquire one, outsourcing the mapping and the change-watching to a provider is a reasonable trade, and the per-document fee is what that service costs.
And if your vendor business is small and stable, the honest answer is often to change nothing. Integration work earns its keep on volume and on error rates. Below a certain level it is a project that makes a spreadsheet slightly more elegant.
Running both is normal
It is worth saying plainly, because people treat this as a one-way door: plenty of vendors run a direct connection for the high-volume document flow and keep an EDI lane for the documents an agreement or a customer insists on. A connector can be configured to the agreement you actually have rather than to a textbook version of the programme, and a hybrid is not an admission of failure. It is often the cheapest correct answer for the first year.
What neither route fixes
Both routes carry what you give them. Neither will make a quantity right, neither will invent a carrier reference that was never captured, and neither will prevent a defect that happened physically on a pallet. If your chargebacks are concentrated in preparation and packaging, the money belongs in your warehouse instructions, not in your integration, and a supplier telling you otherwise is selling the wrong half of the problem. Our chargeback reference separates the data-caused defects from the physical ones.
The other shared limitation is master data. Costs, catalogue mapping, units, pack configurations — if those disagree between your system and Amazon’s, both routes will carry the disagreement faithfully. Distribution businesses hit this hardest, and Odoo for distribution and wholesale covers the catalogue side.
Being straight about our own position
Inwizards builds an Amazon Vendor Central connector for Odoo that uses the Selling Partner API directly, and we also build the Amazon Seller Central integration for 3P sellers. So we have a commercial interest in the API route and you should read the comparison above knowing that. We are an independent software provider and not an Amazon partner; we hold no Amazon certification.
Where we try to be useful rather than persuasive: we will not quote before seeing which documents your agreement covers, which vendor codes and regions you operate, whether direct fulfilment is in play and what your current setup already does. And if what you describe sounds like a working EDI setup with a volume that does not justify a rebuild, we will say so, even though the project would have been ours. Ongoing Odoo support and maintenance is the part of this work we would rather have anyway, and that only makes sense if the integration underneath it was worth building.
Where to start
Three things, in order. Pull your vendor agreement and list the documents it names and any channel it mandates. Pull three months of chargebacks and see how many were caused by data that left your system wrong rather than by something physical. Then price the two routes against your actual document volume rather than your expected one. That sequence answers the question for most vendors in an afternoon, and it answers it with your numbers rather than a vendor’s.