You sell on Shopify. Your business runs on Odoo.<\/p>\n
Orders need to be in both<\/strong>, and re-typing them is neither fast nor accurate.<\/p>\n Three things have to happen for each order:<\/strong><\/p>\n The customer must exist in Odoo \u2014 as an existing record if they have bought before, a new one if not.<\/p>\n The products must be matched to Odoo products.<\/p>\n The order itself must be created, with the right lines, prices and customer.<\/p>\n And it must not create duplicates<\/strong>, however many times the workflow runs.<\/p>\n Shopify can call a URL when an order is placed. That is a webhook<\/strong>, and it is the right trigger here.<\/p>\n Why not poll on a schedule?<\/strong><\/p>\n Delay.<\/strong> Polling every fifteen minutes means orders sit for up to fifteen minutes. For stock allocation and picking, that matters.<\/p>\n Wasted runs.<\/strong> Most polls find nothing. On usage-priced platforms you pay for those.<\/p>\n Missed edge cases.<\/strong> Polling by “modified since” is easy to get subtly wrong, and the failure is silent.<\/p>\n Webhook is immediate and only fires when something happened.<\/strong><\/p>\n One thing it requires:<\/strong> your n8n instance must be reachable from the internet, over HTTPS.<\/p>\n FIGURE 1: THE ORDER SYNC CHAIN<\/p>\n Shopify webhook<\/p>\n Check the order<\/p>\n Match the customer<\/p>\n Create the order<\/p>\n The single most important part of this workflow.<\/strong><\/p>\n Webhooks can fire more than once. Networks retry. A workflow can be re-run during testing. Somebody can replay a webhook while debugging.<\/p>\n Without a duplicate check, each of those creates another order in Odoo.<\/strong><\/p>\n The pattern:<\/strong><\/p>\n Store the Shopify order reference on the Odoo order<\/strong> \u2014 a field holding the source order number or ID.<\/p>\n Before creating anything, search Odoo for that reference.<\/strong><\/p>\n If it exists, stop.<\/strong> Log it and finish successfully. This is not an error \u2014 it is the check working.<\/p>\n If it does not, proceed.<\/strong><\/p>\n Match on the Shopify order ID, not the order name.<\/strong> Names can be reformatted; IDs do not change.<\/p>\n Second most important, and the source of most data quality problems.<\/p>\n Same pattern:<\/strong> search first, create only if not found.<\/p>\n What to match on:<\/strong><\/p>\n Email is the usual choice.<\/strong> Reasonably stable and usually present.<\/p>\n A customer ID from Shopify<\/strong> is better if you store it on the Odoo partner \u2014 it survives an email change.<\/p>\n Not the name.<\/strong> “J Smith”, “John Smith” and “john smith” are the same person and three records.<\/p>\n Two things worth deciding in advance:<\/strong><\/p>\n Guest checkouts.<\/strong> Shopify allows orders without an account. Create a partner anyway, or attach to a generic one? Decide before go-live.<\/p>\n Existing customers who also buy in person.<\/strong> If somebody exists in Odoo from an in-store sale and then orders online, will your match find them? If it matches on email and the in-store record has none, it will not \u2014 and you get a duplicate.<\/p>\n FIGURE 2: THE THREE CHECKS THAT DECIDE WHETHER THIS WORKS<\/p>\n Order already imported?<\/p>\n Customer already exists?<\/p>\n Product matched?<\/p>\n What about guest checkouts?<\/p>\n SKU is the usual link.<\/strong> The Shopify SKU matches an Odoo internal reference.<\/p>\n Which requires them to actually match.<\/strong> In practice they often do not \u2014 different formats, extra characters, products that exist in one system and not the other.<\/p>\n Decide what happens when a product cannot be matched:<\/strong><\/p>\n Fail the order<\/strong> and alert somebody. Safest, and it forces the data to be fixed.<\/p>\n Create the order with a placeholder line<\/strong> and flag it. Keeps the order flowing, but somebody must act on the flag.<\/p>\n Create the product in Odoo.<\/strong> Convenient, and it risks a mess if SKUs are inconsistent.<\/p>\n Most businesses should fail and alert<\/strong>, at least initially. It surfaces the SKU mismatches that would otherwise accumulate quietly.<\/p>\n Beyond customer and products, decide how to handle:<\/p>\n Shipping.<\/strong> A product line, or a delivery charge field?<\/p>\n Discounts.<\/strong> Line-level, or an order-level discount?<\/p>\n Taxes.<\/strong> Does Shopify’s tax match Odoo’s tax configuration? Check this carefully<\/strong> \u2014 mismatched tax produces accounting problems that surface at filing time.<\/p>\n Payment status.<\/strong> Paid in Shopify \u2014 does that mean paid in Odoo, or a pending payment to reconcile?<\/p>\n Order status.<\/strong> Which Odoo state does a new order arrive in? Draft for review, or confirmed?<\/p>\n That last one is a business decision, not a technical one.<\/strong> Confirming automatically is faster; arriving as a draft gives somebody a chance to look.<\/p>\n Orders are money. Silent failure is not acceptable here.<\/p>\n Four things:<\/strong><\/p>\n Retry on temporary failures.<\/strong> Odoo restarting, a brief network problem.<\/p>\n Alert on permanent failures.<\/strong> A product that will not match, a malformed address. A named person, immediately.<\/p>\n Never lose the order.<\/strong> If it cannot be created, the data must be recoverable \u2014 logged, queued, or held somewhere a person can act on.<\/p>\n Reconcile periodically.<\/strong> Compare Shopify order counts against Odoo for the period. If they differ, something failed quietly and you want to know before month-end.<\/p>\n FIGURE 3: A SYNC THAT WORKS AND ONE THAT CAUSES CLEANUP<\/p>\n Working<\/p>\n Causing cleanup<\/p>\n Test these specifically:<\/strong><\/p>\n The duplicate test is the one that matters most.<\/strong> Fire the same order twice and confirm you get one record. If you get two, the workflow is not ready.<\/p>\n Use a webhook<\/strong>, not polling. Orders should arrive immediately.<\/p>\n Check for duplicates on the source order ID<\/strong> before creating anything. Webhooks fire more than once, and without this check you get copies.<\/p>\n Match customers on email or a stored source ID<\/strong>, never on name. Match products on SKU, and decide loudly what happens when a match fails.<\/p>\n And reconcile counts periodically.<\/strong> A quietly missing order is the failure you will not notice until it matters.<\/p>\n Retyping online orders into your ERP?<\/p>\n Get in touch. We build Shopify to Odoo order sync with duplicate prevention and proper customer matching \u2014 the two things that decide whether it stays clean.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The problem You sell on Shopify. Your business runs on Odoo. Orders need to be in both, and re-typing them is neither fast nor accurate. Three things have to happen for each order: The customer must exist in Odoo \u2014 as an existing record if they have bought before, a new one if not. The […]<\/p>\n","protected":false},"author":3,"featured_media":9275,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28],"tags":[],"class_list":["post-9274","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-n8n"],"yoast_head":"\nWebhook, not polling<\/h2>\n
\n
\n
\n
\n
Preventing duplicates<\/h2>\n
Matching customers<\/h2>\n
\n
\n
\n
\n
Matching products<\/h2>\n
What else to map<\/h2>\n
Failure handling<\/h2>\n
\n
\n
Testing before go-live<\/h2>\n
\n
The short version<\/h2>\n