Odoo integrations with e‑commerce, the warehouse and manufacturing systems

We design and build connections between Odoo and the systems manufacturers rely on. We put the exchange of products, prices, availability, orders and documents in order, so every department and sales channel works from the same agreed data.

We establish where each piece of information is created, what triggers its transfer and how systems confirm that an operation was carried out. We also prepare how discrepancies are handled and how the exchange resumes after an outage.

Let's discuss your Odoo integration See how we run an integration project

New connections
Rebuilding integrations
Data synchronisation
Error handling
Testing and monitoring

Every system has to know which data it may change

The store takes the order, Odoo plans its fulfilment and an external warehouse confirms the shipment. When two systems change a status independently or reserve the same stock, moving data back and forth does not by itself serve the customer correctly.

Before building a connection, we agree the master source for each kind of information. We separate data passed on for fulfilment from confirmations of completed operations. That way everyone knows where to correct an error and which version should apply in the other tools.

Let's agree the data sources in your company

An example split in a company where Odoo is the operational ERP

An example split in a company where Odoo is the operational ERP
Information	Possible master source	What we agree in the integration
Item codes, variants and units	Odoo or the system that owns the item master	How to recognise the same material or product in every system.
Descriptions, images and translations	Pimcore, another PIM or Odoo	Which fields each channel receives and where they may be edited.
B2B prices and terms	Odoo or a separate commercial system	How to assign the price list, customer, currency, unit and discount rules.
Stock and availability for sale	Odoo or the WMS, depending on who keeps the records	How to account for reservations, blocks, buffers and update delays.
Customer order	The store, the B2B platform or Odoo	When to pass it on for fulfilment and who may change its contents later.
Production output and dispatch	The system that records the operation	How to transfer quantities produced, dispatched and still to be fulfilled.
Invoices, credit notes and settlements	The agreed finance system	Where the document is created and who is responsible for it afterwards.

Item codes, variants and units

Possible master source

Odoo or the system that owns the item master

What we agree in the integration

How to recognise the same material or product in every system.

Descriptions, images and translations

Possible master source

Pimcore, another PIM or Odoo

What we agree in the integration

Which fields each channel receives and where they may be edited.

B2B prices and terms

Possible master source

Odoo or a separate commercial system

What we agree in the integration

How to assign the price list, customer, currency, unit and discount rules.

Stock and availability for sale

Possible master source

Odoo or the WMS, depending on who keeps the records

What we agree in the integration

How to account for reservations, blocks, buffers and update delays.

Customer order

Possible master source

The store, the B2B platform or Odoo

What we agree in the integration

When to pass it on for fulfilment and who may change its contents later.

Production output and dispatch

Possible master source

The system that records the operation

What we agree in the integration

How to transfer quantities produced, dispatched and still to be fulfilled.

Invoices, credit notes and settlements

Possible master source

The agreed finance system

What we agree in the integration

Where the document is created and who is responsible for it afterwards.

The split depends on the company's architecture. Not every project needs all of these connections, and the receiving system does not have to get the whole source record.

Which systems can Odoo be connected to?

We design the scope around the process that has to run between the tools. Before confirming a solution, we check the interfaces, versions, permissions and data exchange options on both sides. For Odoo we also take the edition, subscription plan and hosting model into account, because they can affect access to the external API, custom modules and how the integration can be built.

Online stores and e‑commerce platforms

Odoo can be connected to Magento 2, Shopify, WooCommerce, PrestaShop and Shopware, among others. These are examples, not a closed list. We assess whether, and how far, other platforms and bespoke stores can be integrated from their available APIs, exports or connectors.

Connecting the store to operational order handling can cover orders, customer data, prices, availability, fulfilment statuses and shipping information. Payments, cancellations and returns are agreed separately, because each of these events may call for different actions in Odoo.

Pimcore and other PIM systems

Linking operational records with product information. We agree identifiers, variants and the set of shared fields, then how data passes to Odoo and to the sales channels. The marketing name and product description can stay in Pimcore or another PIM, while the stock unit and the bill of materials are managed in the ERP.

WMS and logistics operators

Sending warehouse instructions and receiving confirmations of receipt, picking and dispatch. We define the source of stock levels and reservations, how partial shipments are handled and how parcels, batches or serial numbers are identified where the process uses them.

Production and engineering systems

Data exchange with shop-floor recording tools, MES systems or the engineering environment. We assess the need to pass on orders, approved product structures, consumption and output. The scope depends on the available interfaces and how records are kept; machine control needs a separate assessment. How the production process itself works in Odoo is described on the Odoo for manufacturing page.

Accounting and other ERP systems

Connecting operations in Odoo with settlements kept in another tool, or with a system that remains in part of the organisation. We agree the records, documents, payments and balances the process needs. The split of responsibility is signed off with the people who run the accounts.

Marketplaces, B2B portals and reporting tools

Distributing the offer, passing on orders and sharing data for analysis. We check whether the connection should lead straight to the channel or through an intermediary system already in use. For reporting we define the history range, metric definitions and how often the data is refreshed.

Let's check how your systems can be connected

What does an Odoo integration project cover?

The scope describes the whole flow: from a change in the source system to confirmation that the receiving system has handled it. Each connection gets its operating rules, tests and instructions for dealing with problems.

Process and interface analysis

We check which task the integration is to take over, who does it by hand today and which systems take part in the process. We review documentation, sample data, access to test environments and any limits on the vendors' side.

We check which task the integration is to take over, who does it by hand today and which systems take part in the process. We review documentation, sample data, access to test environments and any limits on the vendors' side.

We map source fields to target fields and describe conversions and required values. We agree how products, customers, documents and order lines are matched. A missing match gets a defined handling rule instead of quietly creating a new record.

We describe directions, the moment of transfer, the order and the acceptable data delay. We agree whether a message means a new order, an update or a confirmation of completion. For each status change we define which actions may be triggered on the other side.

We prepare the connection, data transformations, a processing log and retry rules. We separate problems that need a data fix from temporary system unavailability. The scope of alerts and access to diagnostic information is agreed with the client's team.

We verify correct exchange as well as exceptions: an unknown product, no response, a repeated message and partial completion. Users confirm the business outcome, for example that orders, dispatched quantities and documents match.

We agree the initial state of the data and the moment automation is switched on. Replaced paths are switched off according to plan to avoid double processing. We hand over the documentation, test results and post-launch operating rules.

Let's discuss the integration scope

Prices, availability and statuses must mean the same on both sides

These four decisions are made before the connection is built, because they determine what the customer sees in the store and what the warehouse does.

01
Availability for sale has its own definition
The number of units in the warehouse need not match the quantity that can be promised to a customer. Part of the stock is reserved, blocked or set aside for another channel. We agree how availability is calculated and how the store behaves when an update is late. For made-to-order products we separately define how lead times are communicated.
02
A price belongs to a specific customer and terms
A wholesale price list, a quantity threshold, the sales unit and a discount can change the final value of a line. We agree the price source, how amounts are converted and how promotions work in the store. An order should keep the terms that were accepted rather than receive a new price at a later synchronisation.
03
Accepting an order and starting fulfilment are separate events
The document can be passed on once the order is placed, once payment is confirmed or once a sales rep approves it. The choice depends on the sales model. We also describe what can still change after material is reserved, production starts or an instruction reaches the warehouse.
04
Cancellations, returns and corrections have different effects
A cancelled order does not always mean the shipment can be stopped. Accepting a return need not immediately increase the stock available for sale, and a refund does not replace a correcting document. For each event we agree the confirmations and actions required in the systems.

API, an off-the-shelf connector or a separate integration layer?

The choice follows from the scope needed, what the systems can do and what it will cost to maintain later. We test a ready-made solution against the company's scenarios before assuming it will handle the whole process.

Off-the-shelf connector: It can shorten the work if it supports the data, versions and rules needed. We also check the licence, maintenance by the vendor, error handling and access to processing information. Anything outside its scope is described separately.
Dedicated API connection: We consider it when the available interfaces allow the required operations and the process logic needs a tailored solution. We agree authentication, permissions, rate limits and behaviour after an API version change.
Middleware layer or file exchange: A separate layer can manage transformations, ordering and retries for several systems. File exchange is an option where the source provides exports and some delay is acceptable. Each file needs rules for recognition, completeness checks and confirmation of processing.

We check the Odoo variant first

We verify the version, edition, subscription plan and hosting model. In Odoo's current commercial offer the external API is available on the Custom plan, not on One App Free or Standard. This limit applies to Odoo subscription plans and does not mean every Odoo Community installation needs the Custom plan. For Community and self-hosting, we assess integration options from the specific installation, version and available interfaces.

Odoo Online does not allow custom code modules to be installed. If the integration needs its own module running inside Odoo, it needs an environment that allows that kind of development. Odoo.sh supports custom modules but requires an Odoo Enterprise subscription that includes Odoo.sh. Self-hosting can be the alternative, depending on the chosen edition and architecture.

Before recommending anything, we check the conditions of the specific installation and the requirements of the connection. Having Odoo does not in itself settle which integration mechanism will be available.

What happens when data does not arrive or a system does not respond?

An integration has to make it possible to tell what has been done, what is waiting and what needs intervention. We design these rules together with the main flow, because the rest of order handling depends on them.

Identifying the problem: We distinguish, among others, invalid data, missing permissions, a request limit and an unavailable receiver. Each case gets the right response. Retrying an invalid product unit will not fix the record.
Checking before a retry: No response does not mean the operation failed. The connection may have dropped after the document was saved. We agree how to check the outcome and recognise duplicates before an order or a dispatch is created again.
Order of updates: A message received later may carry older data. We design recognition of event order or versions where the source provides them, and otherwise a way to fetch the current state. A delayed message should not restore an earlier status unchecked.
Alerts and ownership: We agree who is notified about an error and what data they need to act on it. A record problem needs the data owner; an interface failure needs the person responsible for the system. Urgency depends on the impact on the process.
Reconciliation after an outage: Once the exchange resumes, we check pending operations and data consistency. The absence of new errors does not confirm that every earlier order was handled. The extent of the comparisons depends on the type of data and how much the connection matters.

What can monitoring cover?The time of the last successful exchange, pending operations, errors that need action, the age of the oldest item and the results of consistency checks. The exact scope is defined in the project.

How do we deliver an Odoo integration, step by step?

Each stage ends with an outcome that can be checked before the next one starts.

01
Discovering the process and systems
We collect sample data, the list of tools involved and a description of how things are handled today. We review documentation, test environments and contacts on the vendors' side.
OutcomeThe integration goal, a map of systems and a list of dependencies.
02
Exchange specification
We agree master sources, identifiers, field mapping, transfer points and exception handling. We describe the expected test outcomes.
OutcomeAgreed scope, acceptance criteria, a quote and a work plan.
03
Preparation and build
We configure or build the connection. We prepare transformations, access, an operations log and error handling. Test data and automated actions are kept apart from the company's day-to-day work.
OutcomeAn integration ready to be checked in the test environment.
04
Technical and business testing
We check data consistency, the effects of operations, retries and behaviour under a larger volume of changes. Process owners confirm the results on the agreed scenarios.
OutcomeTest results and the fixes needed before go-live.
05
Go-live
We agree the initial data, the documents covered by the exchange and the moment the previous mechanism is switched off. We check the first operations and the confirmations that they were handled.
OutcomeA working exchange within the approved scope.
06
Handover and ongoing support
We hand over the documentation, the error-handling instructions and responsibility for each element. We agree monitoring, support and how system version changes are tested.
OutcomeA documented way to maintain and develop the connection.

Let's plan your Odoo integration

How do we check that the integration works correctly?

Acceptance covers both the data written and the outcome of the process on the other side. Tests are matched to the project scope; the example cases show what is worth agreeing before go-live.

How do we check that the integration works correctly?
Scenario	Expected outcome to confirm
An order arrives again with the same identifier	It is recognised as a repeat and no second order is created.
A product is missing or the unit does not match the record	The error is reported with the line that needs a decision; the system does not guess a match.
The receiver saved the document but sent no response	Before a retry, it is possible to tell whether the operation has already been done.
The WMS confirms part of an order in two shipments	Dispatched and remaining quantities and tracking numbers match the actual fulfilment.
A price changes after the order has been accepted	The agreed terms of the existing order are not overwritten without control.
A system is unavailable for an agreed period	Pending operations are visible and resuming leads to controlled processing.
An older message arrives after a newer one	The agreed ordering protection or reconciliation of the current state takes effect.
The number of changes rises at peak sales	Delay and rate-limit handling stay within the agreed criteria for the tested load.

An order arrives again with the same identifier

It is recognised as a repeat and no second order is created.

A product is missing or the unit does not match the record

The error is reported with the line that needs a decision; the system does not guess a match.

The receiver saved the document but sent no response

Before a retry, it is possible to tell whether the operation has already been done.

The WMS confirms part of an order in two shipments

Dispatched and remaining quantities and tracking numbers match the actual fulfilment.

A price changes after the order has been accepted

The agreed terms of the existing order are not overwritten without control.

A system is unavailable for an agreed period

Pending operations are visible and resuming leads to controlled processing.

An older message arrives after a newer one

The agreed ordering protection or reconciliation of the current state takes effect.

The number of changes rises at peak sales

Delay and rate-limit handling stay within the agreed criteria for the tested load.

The acceptance result also sets out what is expected of the team: who corrects source data, who may resume an operation and when the system vendor's help is needed.

Financial documents follow one agreed path

If accounting stays outside Odoo, we define where invoices and credit notes are created and what information returns to the ERP. With the finance team we also agree how customers are matched, payment statuses and how documents are reconciled.

We build the Polish e-invoicing system KSeF into the invoicing architecture. We verify what the Polish localisation offers for the chosen Odoo version and edition, or a connection to the system responsible for e-invoices. We do not assume every Odoo variant provides the same localisation and accounting features. Passing on the data, accepting the document and confirming its further handling should be distinguishable steps.

Before delivery, we agree

which system issues the document and assigns its number
where credit notes are handled and how they link to the original document
which system communicates with KSeF
which statuses, identifiers and confirmations return to Odoo
who analyses rejections and corrects the data

Settlement scenarios are approved by the accounting team. The integration scope follows from the company's requirements and what the systems in use can do.

How much does an Odoo integration cost and how long does it take?

The number of systems does not describe the whole scope. Sending the product catalogue once a day is a different task from handling orders, reservations, partial shipments and corrections between the same tools.

We prepare the quote after reviewing the process, sample data and interfaces. We set out the scope of the connection, the assumptions and the dependencies on third-party vendors.

Discuss the integration scope and quote

What affects the budget and timeline?

Number of flows: Products, prices, availability, orders, shipments and documents, each separately.
Complexity of rules: B2B price lists, units, document changes and partial fulfilment.
Quality of interfaces: Available operations, documentation, limits and test environments.
Data quality: Identifiers, duplicates, missing fields and inconsistent dictionaries.
Exchange volume: Number of records, frequency of changes and acceptable delay.
Exception handling: Retries, consistency checks, alerts and the diagnostics required.
Terms of use: Connector licences, the Odoo edition and plan, the hosting model, required API access and middleware costs, where applicable.
Go-live: Moving pending operations, replacing the old integration and the teams' availability for testing.

We separate the cost of delivery from later maintenance. Before go-live we agree who responds to errors, updates access and checks the connection after changes in Odoo or external systems. Support hours and response times follow from the agreed terms of cooperation.

FAQ: Odoo integrations

Answers to the questions asked before the first conversation about connecting Odoo with other systems.

Let's discuss your Odoo integration See all Odoo services

Connections are possible with Magento 2, Shopify, WooCommerce, PrestaShop and Shopware, among others. Integrations can use off-the-shelf connectors or solutions built on the API. In each case we check version compatibility, the available operations and the scope required, for example prices, orders or partial shipments. Having an API does not mean the connection works without configuration and integration work.

Yes. We review the documentation, the ability to read and write data and the access conditions. A connection through the API, a middleware layer or file exchange may be needed. Only after that review do we confirm which processes can be supported, with what delay and to what extent.

We start by assessing the code or connector, the configuration, the error log and how the data is processed. We establish the cause of the problem and the scope of changes. If the current solution cannot remove it, we present a rebuild option. Ongoing care for a running system is described on the Odoo maintenance and development page.

The acceptable delay is agreed separately for each flow. It depends on interfaces, limits and load. Store availability may need frequent updates, while a report can be refreshed periodically. Using an API does not by itself mean instant synchronisation.

That needs shared availability and reservation rules, and it has to take the exchange delay into account. We check, among other things, channel buffers and the moment an order is confirmed. Sending stock levels at intervals does not in itself guarantee that the last unit will never be sold twice at the same time.

It may be, if it supports all the scenarios and versions you need. We also check how it is updated, access to diagnostics and error handling. Missing features or business rules may need an extension or a different solution.

Not to the same extent. In Odoo's current subscription offer the external API is available on the Custom plan, not on One App Free or Standard. Odoo Community is not one of those subscription plans, so for Community installations or self-hosting we check the technical options of the specific version and environment separately. Before choosing a solution, we always verify the edition, plan, version, hosting and the communication method required.

For a one-off data transfer, a well-prepared import is enough. A regular exchange also needs control of file versions, duplicates, errors and completeness. The choice depends on whether it is a migration or an ongoing process. Data migration for a new system is described on the Odoo implementation page.

We apply agreed rules for logging the backlog, checking outcomes and retrying operations. Data errors are routed for correction, and temporary failures are handled by the retry rules. Once the exchange resumes, we verify consistency within the agreed scope.

We can design how the order is passed to a process in Odoo that triggers the right actions according to the configured rules. First we agree the acceptance conditions, product links, material availability and the moment fulfilment starts. The integration itself does not replace configuring the production process, which we cover on the Odoo for manufacturing page.

Access is matched to the operations the connection needs. We agree technical accounts, permissions and how credentials are stored and renewed. Receiving systems get only the fields the agreed process needs, and diagnostic logs are also limited to the information required.

At the start we name the owner of each system and the vendor responsible for its interface. We agree who provides the test environment, makes changes on their side and takes part in acceptance. Aurora's scope and the dependencies on other contractors are set out in the proposal.

A working connection within the accepted scope, documentation of mappings and rules, test results and error-handling instructions. We also agree who is responsible for monitoring, access, updates and further development. The scope of code and licences handed over follows from the chosen solution and the contract.

Let's connect Odoo with the processes that still rely on retyping data by hand

Tell us which systems should exchange information, what data is needed and what causes problems today. In the first conversation we will establish whether you need a new connection, a fix to an existing one or tidying up the process in Odoo first.

You do not need a ready specification. An example order, file or error showing the current situation helps, as do the names and versions of your systems, the Odoo edition, the subscription plan (if applicable), the hosting model, the scope of data and an approximate number of orders or changes.

Małgorzata Gudalewska, Head of Sales at Aurora Creation

Małgorzata Gudalewska

Head of Sales

+48 664 531 867 [email protected]

[email protected]ul. Jana Henryka Dąbrowskiego 28, 15-872 Białystok, Poland

Enquiry sent

Thank you, we'll get back to you within 1 business day.

The enquiry has not been sent

We have marked the fields that need filling in or correcting.