Odoo PrestaShop connector,what I decide before plugging it in

You sell on PrestaShop, your stock and invoices live in Odoo, and someone is still retyping orders by hand. The first idea is to buy an Odoo PrestaShop connector from the app store and plug it in over an afternoon. That can work. But the module is not the hard part. The hard part is the set of decisions you need to make before installing it, and which people often forget to make.

I have led an integration between an ERP and an online shop, and I build content machines that publish to this blog on their own. Both are jobs where software acts without anyone watching, and where a mistake repeats itself quietly. I am not an Odoo integrator and I don't do ERP overhauls. What follows is what I decide and what I check before a connector touches a real order.

01Off-the-shelf connector or custom development

The first question, often skipped: do you need two systems at all? Odoo has its own shop, and its documentation describes it as a modern open-source online store. If your PrestaShop site has no specific modules, no carefully built theme and no search rankings to protect, the question is worth asking before you pay to make two tools talk to each other.

If both stay, there are two routes. An off-the-shelf module covers the usual flows (products, stock, orders, customers) and is cheap to set up. Custom development does only what you need, but someone has to maintain it.

My rule of thumb is simple. If your business rules fit inside a module's settings (one warehouse, one shop, standard taxes), I take the module. If every meeting turns up another exception, several warehouses, customer-specific terms of sale, bundled products, I start by writing down the list of flows and only choose afterwards.

02Decide which system owns each piece of data

This is the decision that saves the most trouble. For each piece of data, one system is the reference and the other only receives. When both can change the same thing, you end up with a product page edited in PrestaShop and overwritten the following night by Odoo, with nobody understanding why.

Here is the split I suggest as a starting point, to be discussed with the team:

• product records, their terms of sale and stock go from Odoo to PrestaShop;
• orders and customers go from PrestaShop to Odoo;
• order statuses (shipped, cancelled) and tracking numbers go back from Odoo to PrestaShop;
• sales copy, images and SEO stay in PrestaShop, where the ERP has no business touching them.

For each flow, I also write down the frequency and what a delay costs. Stock that is an hour late can sell a product that no longer exists. A product page that is a night late bothers nobody. All of this fits in a one-page table, which I version: on an integration between an ERP and an online shop, the specification changed at almost every meeting, and numbering the versions was the only way to make sure everyone was talking about the same document. I describe the method in how I write an integration specification.

03What the Odoo and PrestaShop APIs impose

A connector, even a bought one, goes through both systems' APIs. A few constraints from the official documentation change the way you design the flows.

On the Odoo side

The first is commercial: the documentation states that access to data via the external API is only available on Custom pricing plans, not on One App Free or Standard. Check this before anything else.

The second is technical. With the new JSON-2 API, each call runs in its own transaction, and the same page says you cannot chain several calls inside a single one. Creating an order and then its lines in two calls means risking a half-created order if the second call fails. The documentation recommends calling a single method that does all the related work.

The third is about access. API keys cannot last more than three months, and Odoo recommends a dedicated bot user with the minimum rights. A key that expires quietly stops the sync, so someone needs the date in their diary. Finally, the older XML-RPC and JSON-RPC APIs are deprecated, with removal announced for Odoo 22. A connector that still relies on them has an end date.

Odoo gave a talk on these changes, Odoo API 101 at Odoo Experience 2025, whose chapters cover API keys, transactions, limits on request volume and versioning. I could not read the transcript, but the outline confirms that these topics belong in any serious integration.

On the PrestaShop side

The webservice works with a key whose rights are set resource by resource. The documentation recommends sending it in an authorisation header rather than in the URL, and notes that since version 8.1 the webservice can output JSON but cannot read JSON inputs: writes are still in XML.

The trap I would watch first is stock. PrestaShop holds it per product, per combination and, where relevant, per shop. Every Odoo size or colour must therefore match exactly one PrestaShop combination. If the match is made on a label rather than a stable reference, the first rename breaks everything. It is the same lesson as mixing centimetres and millimetres between two tools: the reference data has to be explicit.

04Check a connector before installing it

I don't judge a module by its sales page. I judge it by what it does when things go wrong. Here is my list, in the order I work through it.

Before buying

1. Supported versions: your Odoo version, your PrestaShop version, and the date of the module's last update.
2. The API it uses on the Odoo side: JSON-2 or the deprecated older APIs.
3. The direction of each flow, and whether you can switch one flow off without switching off the others.
4. How it handles combinations, taxes and multiple shops if you have them.

In a test environment

1. Import the same order twice, cutting the connection halfway through the first attempt. A retry must pick up where it stopped without creating a duplicate. It is a rule I apply to my own publishing pipelines: every step is logged, and running it again recreates nothing.
2. Send an order with a reference Odoo does not know. I want a visible, readable error, not an order that vanishes.
3. Let the API key expire. The connector must say so, somewhere a person actually looks.
4. Compare the stock shown on the product page, viewed as a logged-out visitor, with the stock in Odoo, on ten or so references with combinations.

The third point matters more than it seems. In my content machines, a check that did not run counts as a red, never as a green by default. A connector that has been silent for three days looks a lot like a connector that works, right up to the first customer who phones. For full acceptance testing, my acceptance testing and go-live checklist applies as it is.

05What breaks after go-live

On launch day, everything seems to work. It is the following weeks that bring out the forgotten cases: an order paid in instalments, a credit note, a product deleted in PrestaShop but still active in Odoo. I keep a list of these cases and turn it into a test set.

I did this at Moonworkers, my own company, on a different subject: an oracle written from the official texts replayed several hundred contribution cases and found four one-penny errors caused by a rounding rule. I tell that story in the article on test oracles and on the Moonworkers page. For a connector, the equivalent is more modest: twenty or so typical orders, replayed every time the module or Odoo is updated.

Because updates do come. Odoo's documentation says that each major version is supported for three years, and that a database with custom modules cannot be upgraded until those modules exist for the target version. Your connector is one of those modules. If its vendor stops maintaining it, your Odoo upgrade stops with it.

One honest limit to finish: all this scoping work has a cost, and it is not always justified. For a small shop with a hundred or so references and a single warehouse, a well-rated module and an afternoon of testing are often enough. I would not bring out the heavy machinery for that.

06Where to start on Monday

Take a sheet of paper and draw three columns: the data, the system that owns it, the frequency. Fill it in with the person who prepares orders and the person who does the accounts, not only with whoever will buy the module. Then check your Odoo plan and your versions. Finally, ask the connector's vendor to show you, in a test environment, what happens when the same order arrives twice.

If you have a project like this and want someone to scope the flows and steer the suppliers, my project and technical direction services are described on the site. We can talk about it.