A native connector in Odoo 19 makes sense when Odoo is in charge of stock, orders, shipments and invoices: every status lives once, on the record where the team works. Middleware makes sense when you only need to move data without taking operational decisions, or when nobody is going to maintain code inside Odoo. Connecting an API once was never the problem: the problem is keeping orders, stock, errors and traceability under control as the operation grows.
Key idea: the question is not "native" or "middleware", but where each status lives and who checks it when the numbers disagree.
The real difference is not in the API
Amazon's, Mirakl's or a carrier's API is the same whoever calls it. What changes is who stores the result and where the person preparing the order sees it: that is the difference, not the API.
If Odoo has to reserve stock, prepare orders, generate delivery notes, create labels and send the tracking back to the channel, native integration keeps traceability where the team works. With an intermediate layer, each step exists twice and the two copies only match if somebody checks.
When to choose a native connector in Odoo
It makes sense when Odoo is the master system for product, stock, orders, logistics and invoicing. Also when you need your own rules: multi-warehouse, validations before sending, retries, per-order call logs and errors the user sees on their own screen.
In our marketplace connectors, the record of every call is an Odoo model with method, endpoint, parameters, request body, response status and body, attempt and duration in milliseconds, with configurable purging. It filters like any Odoo list, with no external panel involved.
When middleware can work
If you only move simple data between two systems, with no complex operational decisions, middleware can speed up the launch. Also if several ERPs sell on the same channels and the published stock has to be the sum of them. And above all, if nobody, in-house or an Odoo partner, is going to maintain code inside the ERP.
The risk appears when the team checks three panels to know whether an order is sold, reserved, shipped or failed: that day the middleware has stopped transporting and started holding state.
What middleware costs in daily work
The figure that matters is not the monthly fee: it is the tasks that appear as soon as there is an intermediate layer and nobody budgets for. There are four.
- The double master. The product is created in Odoo and, on top, mapped in the middleware: SKU, channel category, mandatory attributes. Every new product, every EAN change and every new variant is two edits. With a native connector, the channel mapping is one more field on the product in Odoo.
- Status reconciliation. A marketplace order has three truths: the channel's, the middleware's and Odoo's. When they disagree —an order cancelled on the channel that still reserves stock in Odoo— somebody finds out by hand. With a direct connection there are two, and the remote status is stored exactly as the API returns it next to the sale order, with the time of the last sync.
- Who reads the log. A failed call lives in the provider's panel, with its own login and retention. Whoever sees the order stuck in Odoo rarely has access to that panel. If the log is an Odoo model, the person with the problem sees it, on the same screen.
- The version upgrade. When Odoo moves from 18 to 19, the middleware promises its side does not change. The one that does change is Odoo's: the provider's bridge module, the fields it reads and the webhooks it expects. You do that migration anyway, at the provider's pace and not yours; we publish for 19, 18 and 17 at once, as explained in maintaining a module on three versions.
If you already pay for an intermediate layer and suspect it is surplus, the channel-by-channel cut-over plan is in from middleware to a native Odoo connection, told from our own Amazon migration in production.
Where traceability gets lost
The exact point is the delivery. In Odoo, the delivery (stock.picking) inherits from mail.thread and its state is tracked, so every move to "done" is recorded with date and user. With the delivery module, the carrier's tracking number is a field on the delivery itself (carrier_tracking_ref). All of that is standard.
What Odoo does not know out of the box is whether that tracking reached the marketplace. With middleware, the chain order → delivery → tracking → confirmation to the channel splits in two: the first two links in Odoo, the last two in the provider's panel. The delivery chatter says "done", and the proof that the buyer saw their number sits in another system.
A native connector closes the chain in the same place. In our Mirakl connector, validating the delivery triggers the tracking push if the instance has it enabled, and the result is written into the chatter: one note if it was sent, another with the error if it failed, and a different one if the delivery had no tracking number and nothing was sent.
Native is not magic either: 32 defects with green tests
The uncomfortable part is ours: "native" means the code lives in Odoo, not that it works. We audited one of our own marketplace connectors before putting it in front of a real seller. The suite gave 236 of 236 green, on real Odoo.sh builds for 19, 18 and 17. Underneath there were 32 real defects: 20 in the API contract and 12 in Odoo version handling.
The contract ones were parameters the API required and were not sent, and response fields read under the wrong name, which return None and raise nothing. Four only surfaced by calling: the pagination header arrived relative and from page one onwards no order was imported; a 403 for quota did not come in the documented format and was read as missing permissions, stopping the whole sync. The version ones were Odoo's own: a cron that on 17 runs once and switches itself off, a groups field spelled differently from 19 on, a list view that 17 rejects. Half of them gave no error: they gave silence.
The full case —including a second connector with 163 of 163 green that had never written a single log line— is in the tests were green and the connector was broken. The conclusion for anyone comparing: ask the native connector the same you ask the middleware. That it is actually installed on your version, not just that it compiles; that it has been checked against the provider's specification, not its own mocks; and that it has made at least one real call per endpoint family. If you inherit it, the list is in auditing an inherited Odoo connector.
Decision checklist
- Where is stock reserved, and how many systems keep a copy of the available quantity?
- Who creates the delivery note and the label?
- Where does the error show when an API call fails, and does the same person who sees the order see it?
- Does tracking flow back to the channel automatically, and is it recorded on the delivery that it did?
- Can you retry without duplicating orders or shipments?
- Who migrates the connector when the next Odoo version ships, and how soon?
- Has it actually been installed on your version and tested against the provider's sandbox?
The order in which several channels are connected depends on which one publishes the stock: we cover it in selling on several marketplaces from a single Odoo. The connectors that already talk to Amazon, Mirakl, ManoMano, AliExpress and the carriers are in the catalogue and in Odoo integrations and automation; if it is for your own software, see Odoo connector for your software.
Frequently asked questions
Is a native connector always better?
Not always. It is better when Odoo is the operational hub and you need business rules, traceability and control from the ERP. If Odoo only receives a file at the end of the process, or nobody is going to maintain code inside Odoo, middleware is the sensible option.
Can I combine both approaches?
Yes, but you should define which system has the final say over stock, orders, logistics and errors, and leave no status that exists in both at once without a daily comparison.
How do I check a native connector works before trusting it?
Actually install it on your Odoo version, compare what it sends and reads against the provider's specification and make one real sandbox call per endpoint family. A connector of ours with 236 of 236 tests green had 32 defects that only surfaced that way.
What happens to the native connector when a new Odoo version ships?
It has to be migrated, and it is worth knowing who will do it before deciding. On Odoo 17 an ir.cron without numbercall takes the value 1 and deactivates itself after the first run; that field no longer exists on 18 or 19, and the change gives no warning at install time. Our connectors are published for 19, 18 and 17.
Useful links inside FlexigoTech
What we do about this
Want us to review your case?
We look at your channels, stock, carriers and Odoo version to propose the cleanest path, and we tell you plainly if the middleware should stay. Email comercial@flexigobe.com or call +34 616 809 504.