Odoo and Shopify Integration

There is no native connector

Worth stating plainly because a lot of published material implies otherwise: Odoo 19 contains no Shopify module, in Community or Enterprise. Odoo ships native payment providers and some marketplace support, and Shopify is not among them.

So the question is never "how do I turn it on". It is which of three routes you take, and who maintains it in twelve months.

A third-party app from the Odoo Apps Store. Fastest to start and the usual choice. Quality varies enormously. The things to check are which Odoo versions it currently supports, when it was last updated, and whether the publisher answers questions on the listing. A connector abandoned one version back is a migration problem attached to your order flow.

A middleware platform. An integration service with connectors for both. More expensive monthly, less to build, and it brings retries and monitoring you would otherwise write yourself. Sensible when Shopify is one of several systems.

A custom build. Full control over the mapping, full ownership of the maintenance. Justified when your flow genuinely does not match what off-the-shelf connectors assume, and over-chosen by teams who have not looked at the alternatives properly.

Decide what each system owns

Before evaluating any of them, settle ownership. Almost every Shopify and Odoo project that goes wrong went wrong here.

Products. Usually Odoo owns the catalogue, cost, internal reference and stock, while Shopify owns the storefront description, images and web-specific fields. Splitting descriptions in two is not duplication, it is what prevents a marketing edit being overwritten by an ERP sync at 2am.

Stock. Odoo, in almost every case. It knows about incoming purchase orders, reservations, returns and multiple locations. Shopify knows what it has been told. Push stock out of Odoo, do not pull it back.

Orders. Shopify creates them, Odoo fulfils them. The order flows one way and its fulfilment state flows back.

Customers. Shopify usually creates them, Odoo enriches them. Match on the Shopify customer id stored on the partner, never on email.

Prices. Pick one. Both systems have full pricing engines, and running both is how a customer sees one price and gets charged another.

The mappings that actually cost time

Variants. Both systems have a product-with-options model, and they do not agree on the details. Shopify has a fixed option limit and its own combination rules; Odoo has attributes and generated variants. A catalogue with deep variant structures is where connector projects overrun.

Taxes. Shopify calculates tax its own way. Odoo has fiscal positions, tax groups and rounding rules. Decide which figure is authoritative for the invoice, then reconcile deliberately, because sub-cent differences on thousands of orders become a real reconciliation problem.

Payouts. Shopify Payments settles net of fees, in batches, on its own schedule. What arrives in the bank is not the sum of the orders. Model the fees as a cost and reconcile against the payout, or the bank reconciliation never clears.

Shipping. Shopify charges the customer a shipping amount; Odoo tracks the delivery. These are different numbers with different purposes, and treating them as one produces a margin figure that is quietly wrong.

Refunds and partial returns. Frequently the last thing implemented and the first thing that breaks in production. Test them before go-live, not after.

Getting it live

Sequence the sync in dependency order: products first, then customers, then open orders. Historical orders usually should not come across at all, for the reasons covered in legacy data migration.

Run both systems in parallel briefly, with the sync one-way, and compare. Order counts, stock figures on a sample of products, one full order end to end including its payout.

Then watch stock specifically for the first fortnight. Overselling is the failure customers notice, and it is nearly always a sync frequency problem rather than a mapping problem.

What to monitor afterwards

Alert on silence, not only on errors. The failure that hurts is a sync that stopped running, and an error-only alert cannot see it. Add a check for "no successful order sync in the last hour" and it will earn its keep.

Watch for duplicate customers as an early warning too. They mean matching is falling back to something unstable, which is the pattern described in integration architecture.