Solution · By integration

A connector links Shopify to Odoo. Keeping the odd order from breaking your warehouse is another matter.

The happy path —product published, order imported, stock pushed— any connector syncs. What jams is the partial refund, the bundle that is three items inside Odoo, the order the customer changes afterwards and the webhook that one day never arrives. We build the AI layer that handles that, and we ship it to production.

Ship it in my business See how it works

The problem

Shopify is where they buy. Odoo is where it gets done. The connector covers the textbook order; someone repairs the rest by hand.

The connector imports the order, but the Shopify variant does not match the Odoo reference —size, color, format, selling unit— and someone ends up pairing products by hand every week.
You sell a bundle or a kit: in the store it is one item and in Odoo it is three with their own stock, so the delivery order comes out wrong, or does not come out at all until someone breaks it down.
The partial refund —two of three items, shipping not refunded— has no automatic path: it comes in as a ticket and ends as a hand-typed credit note.
Stock drifts between store and warehouse: Shopify has its locations and Odoo has its own, and the mapping breaks the moment you add a warehouse, a reservation or an order being picked.
One day the webhook does not arrive —the endpoint changed, the subscription lapsed after an app update, the process died— and the missing orders only surface when a customer asks where theirs is.

Cost of staying the same

You have two expensive, well-chosen systems joined by a connector that only covers the textbook order, and a person patching the rest: re-pairing variants, breaking down bundles, typing credit notes, reconciling stock and hunting for orders that never landed. That work shows on no invoice, but it shows elsewhere: shipments going out late, sales of product you did not have, refunds credited weeks later, and an inventory nobody fully trusts anymore. The integration is not broken; it is incomplete, and a person pays the difference every day.

The solution

An AI layer between the Shopify Admin API and the Odoo External API that handles what the connector does not cover

1We start from what you already have. If you run the native Odoo connector or an app from the Shopify App Store, we do not rip it out: we leave it on the happy path —publish product, import order, push stock— and build on top only what requires judgment, which is where the hours go.
2We match the catalogs properly. The AI pairs Shopify variants with Odoo references by attributes, codes and description, proposes the doubtful ones with its reasoning and learns from every correction, instead of leaving you a mapping table that ages on its own.
3We unjam the order that is not standard: a bundle or kit that becomes several Odoo lines, discounts and promo codes booked where they belong, shipping and taxes by delivery country, a new or duplicate customer, and an order changed or cancelled after it was confirmed.
4We close the reverse cycle, the one almost nobody has built: a full or partial Shopify refund turned into its return and its credit note in Odoo, with items going back to the right warehouse and shipping handled per your policy.
5We map Shopify locations against Odoo warehouses and sync real available stock —net of reservations and picks in progress—, not the theoretical number, so you stop selling what you do not have.
6We leave it with a net and measured: idempotent retries and a periodic reconciliation so a lost webhook is not a lost order, plus a panel showing what share goes through alone, what escalates to a person, and with what context.

What changes

What you stop losing

The odd order stops being a manual ticket: the bundle breaks into its lines, the discount is booked where it belongs, and the customer’s later change propagates to Odoo without anyone reopening the order.
Mechanism
The partial refund stops ending as a typed credit note: it comes in through the same path as the sale, with its item back in the right warehouse and shipping per your policy.
Mechanism
The order lost to a webhook that never arrived stops being discovered by a customer complaint: reconciliation catches it and reprocesses it without duplicating it.
Mechanism
What we measure: % of orders reaching Odoo untouched, variant and bundle matching accuracy, stock discrepancies per week, time from the Shopify refund to its Odoo credit note, and orders recovered by reconciliation.
What we measure

Spec sheet

Work it removes: hand-repairing what the connector does not cover: pairing variants, breaking down bundles, typing credit notes for partial refunds, reconciling stock across locations and hunting for orders that never landed
Typical setup: 2–5 weeks
Input: a Shopify event: an order created, changed or cancelled, a full or partial refund, an inventory or catalog change
Output: the right document in Odoo —sales order, delivery order, invoice or credit note— with its product, warehouse, tax and customer
Works with: Shopify (Admin API + webhooks)Shopify PlusOdoo (External API, XML-RPC / JSON-RPC — Odoo Online, Odoo.sh or self-hosted)Odoo Shopify Connector (nativo)
Can connect to: Your Odoo modules (Sales, Inventory, Invoicing, Contacts)Your Shopify locations and your Odoo warehousesYour carrier and your payment gatewayYour bundle, pricing, tax and refund rules
What we measure: % of orders reaching Odoo untouchedvariant and bundle matching accuracystock discrepancies per weektime from the Shopify refund to its Odoo credit noteorders recovered by reconciliation
Good fit for: stores selling on Shopify and executing in Odoo —stock, warehouse, invoicing— that have already hit the exceptions the connector does not cover
Not a fit for: anyone selling a small, stable catalog with no bundles and barely any refunds: there the native connector is enough and no layer on top is needed

Frequently asked questions

For the happy path, yes, and that is why we do not touch it: publishing the product, importing the order and pushing stock, they do well. Where they fall short is everything that requires judgment and differs per business: pairing a variant that does not match by code, breaking a bundle into its Odoo lines, turning a partial refund into its credit note with shipping handled per your policy, or deciding which warehouse serves which order. Those cases are a minority in volume and a majority in hours. We build that layer on top of the connector, not instead of it.

You can, and if your case is "order in, order created", build it and do not call us: we mean it. What jams is the exception, which in ecommerce is not rare —it is the catalog with variants, the bundle, the partial refund, the last-minute change—. A flow that pairs products with judgment, breaks down kits, reconciles what never arrived and does not duplicate on retry stops being a ten-step scenario and becomes a system with state. In a tool that charges per operation, that gets paid every month and breaks every time someone touches it. Our take: if it fits in three steps, use Make. If your month goes into fixing exceptions, that is where we come in.

That is why it starts with a net. Anything that moves stock or touches accounting starts in proposal mode: the AI leaves the match or the document prepared in Odoo and a person approves it, and you release autonomy case type by case type —first the simple domestic order, then the bundle, last the partial refund— as accuracy climbs. Anything doubtful always escalates to a person, with the order summarized and a direct link to Shopify. And everything is logged: what was created, under which rule and from which event. No trace, no autonomy.

Want it running in your business?

You’ve pinned the problem. We ship the fix and leave it measured.

See the service