The question nearly always arrives at the same moment: you already sell on Amazon, you already run Odoo, and somebody has just sent you a quote for a platform that sits in the middle and connects everything. The decision is not «expensive or cheap». It is who owns the credentials, how many minutes pass between Amazon knowing something and your warehouse knowing it, and who you ring on the day SP-API changes.
There are three routes, not two
Paid middleware: an external service talks to Amazon, normalises the data and pushes it into Odoo. Native connector: a module inside Odoo that talks to SP-API directly. And a third one almost everybody forgets: Odoo Enterprise ships its own Amazon connector, which imports orders and creates the customer and the delivery. If all you need is for orders to land and you already pay for Enterprise, start there before buying anything. The differences are broken down in the comparison of Amazon connectors for Odoo.
The cost you see and the cost you do not
The monthly middleware fee is the visible part, and rarely the expensive one. The expensive part is that cost grows with your success: order tiers mean the better you sell, the more you pay, and that money buys no new capability. A native connector has the opposite profile, and the full story has to be told: you pay once, then you maintain. Amazon retires SP-API versions, Odoo ships a major release every year, and somebody has to be behind it. An unmaintained module ends up dearer than any subscription.
Latency: where the minutes get paid for
Every hop adds time. Amazon → middleware → Odoo is two queues instead of one, each with its retries and its sync window. Where that gets paid for in money is shipping confirmation: Amazon gives you a deadline to upload tracking and penalises lateness in account metrics, a problem covered in when tracking never reaches Amazon. Now the other half, which is equally true: part of the delay does not come from the middleman, it comes from Amazon. FBA inventory is published by asynchronous report, and a native connector performs no magic there either.
Who owns the credentials and where buyer data travels
With a native connector you authorise the application in your own Seller Central: the refresh token lives in your Odoo and you decide how the API call quota gets spent. With middleware, buyer data — name, address, phone — passes through a third party. That is not bad in itself: Amazon has a data protection policy and there are serious providers who comply with it. But it is a question you have to ask and see answered in writing, not a detail you settle during the demo.
Four questions before signing, valid for both models: whose refresh token is it? Who processes buyer data? What do I take with me if I leave, SKU mapping and order history included? How many hours until there is a patch when Amazon changes something?
Who fixes it when Amazon changes the API
Amazon changes. It versions endpoints, switches the old ones off and tightens call limits. With middleware, the vendor fixes it and you wait; usually fast, because the failure hits all their customers at once. With your own module, whoever built it fixes it, and there the answer depends entirely on who you bought from and on whether they maintain the module on Odoo 17, 18 and 19 or only on the version they sold you. The specific failures that come up most are in common SP-API errors in Odoo.
When middleware is the right answer
When you sell on eight channels and Amazon is just one of them: paying a fee to avoid maintaining eight integrations is a good deal. When you are testing the channel and do not know whether you will still be there in six months. When you have no technical team and no partner and something has to work on Monday. And when it is already built and working: replacing an integration that does not hurt spends money and risk on improving nothing. If the only reason to move is that it «sounds expensive», compare a year's invoices with what maintaining a module costs first.
When native pays off, and what we do
It pays off when volume grows, when channels narrow to two or three serious ones, or when the operation needs more than orders: settlements reconciled line by line, FBA as a real location, returns and reimbursements. The Amazon connector for Odoo works against SP-API with your own credentials, on Odoo 17, 18 and 19, and Odoo 20 the day it ships. The inventory side is covered in FBA as a warehouse inside Odoo. And if what you run today is middleware, how to migrate without stopping the operation sets out the order of the steps.
Frequently asked questions
Can I run middleware and a native connector at the same time?
During a migration yes, but only one may write. If both confirm shipments or publish stock, Amazon receives contradictory instructions and duplicates appear. You split by channel or by data type, never by whichever gets there first.
Does a native connector need an Amazon developer account?
The application has to be registered under a developer profile, but the one who authorises it is you, from your own Seller Central. The refresh token that authorisation produces is stored in your Odoo and you can revoke it whenever you like. We do not resell access.
Do I take the history with me if I leave the middleware?
What you truly need is the SKU mapping and the open orders. Closed history can be brought over or left archived: it does not block go-live. Asking in writing how it is exported, before signing, avoids the surprise.
Useful links inside FlexigoTech
What we do about this
Deciding between middleware and your own module?
Tell us how many orders a month you move through Amazon, how many other channels you sell on and what the middleman costs you today. If the right answer is to stay where you are, we will say so. Write to comercial@flexigobe.com or book a call.