Start with the question nobody asks

Before designing any integration, ask this: should these two systems be one system?

A company running Odoo and a separate stock package, syncing between them, is paying twice — once for both systems, and again for the bridge that keeps them agreeing. Every integration is a permanent maintenance cost.

Sometimes the second system is genuinely necessary. A bank. A government filing portal. A shipping carrier. Specialised equipment.

Often it is not. It is there because it came first, and nobody revisited it.

The best integration is the one you did not need to build.

With that said, here is how the ones you do need actually work.

The three patterns

Almost every integration is one of three shapes.

One-way in. Another system sends data to Odoo. A payment gateway posting confirmed payments. A website sending orders. A scanner writing stock moves.

One-way out. Odoo sends data elsewhere. A reporting tool reading sales figures. A shipping carrier receiving delivery details.

Two-way. Both systems update each other. Product and stock data synced with a marketplace, for example.

Two-way is the one to be careful with. If both systems can change the same record, you need a rule for what happens when both do at once. Most integration failures trace back to this being left undefined.

How data actually moves

Three mechanisms. The choice affects cost and how quickly things are reflected.

Scheduled sync. A job runs on a timer — every fifteen minutes, hourly, nightly — and moves whatever has changed.

Simple, cheap and predictable. The downside is delay: for a period, the two systems disagree. For most business data, that is fine.

Real-time via API. One system calls the other the moment something happens.

Immediate, but more work to build. Needs proper handling of what happens when the other end is unavailable.

Webhooks. One system notifies the other that something changed, and the other reacts.

Efficient, because nothing polls for changes that have not happened. Requires both sides to support it.

Choose based on how much a delay actually costs you. Real-time is more expensive to build and to maintain. Many companies pay for it where a fifteen-minute sync would have been invisible.

The design decisions

Four questions to settle before anyone writes code. Getting these wrong is what makes integrations fail.

Which system owns each field?

If both hold a customer’s address, one of them must be authoritative. Write it down field by field. “Odoo owns pricing, the marketplace owns stock” is a decision — leaving it unstated is not.

How do records match?

You need a stable identifier that links a record in one system to its counterpart in the other. An internal ID, a SKU, a reference code.

Not the name. Names get edited, and the day someone corrects a spelling, the link breaks silently.

What happens on failure?

The other system will be down at some point. Yours will too, during an upgrade.

A good integration queues, retries, and alerts a person if it still cannot get through. A bad one drops the record and stays quiet.

Silent failure is the worst outcome, because you discover the gap weeks later with no record of what was lost.

Who is notified?

There must be a named person who hears about failures. Not a shared inbox nobody reads.

Common integrations

Payment gateways. Usually available as ready-made modules. Little custom work, and the main task is correct configuration.

Shipping carriers. Also often available as modules. Rates, labels and tracking numbers.

Banks. Odoo Enterprise supports direct bank feeds in many countries. Where it does not, file import is usually enough.

Marketplaces and webshops. These are two-way, and they are the ones that need care. Stock, price and order data all moving both directions.

Government filing. Tax portals, e-invoicing. Requirements are strict and often change with legislation. Budget for ongoing maintenance rather than a one-off build.

Check first whether a module already exists. Odoo’s app store has thousands. A configured existing module beats a custom build almost every time — somebody else maintains it.

Ongoing costs

An integration is never finished. Four things need budget:

Version upgrades. Odoo’s data model changes between versions. Integrations need testing, sometimes reworking.

The other side changing. Third-party APIs change too, often with short notice.

Monitoring. Somebody has to notice when it stops working.

Documentation. Which is only useful if it is kept current.

A rough guide: assume ongoing maintenance is a real annual line, not zero. Companies that budget for it are not surprised. Companies that do not end up with integrations nobody dares touch.

What to ask before commissioning one

• Does a module for this already exist?
• Could we remove the need for the other system entirely?
• Which system owns each piece of data?
• How are records matched, and what if the identifier changes?
• What happens on failure, and who is alerted?
• Who owns and documents this after delivery?

The short version

Integration is not primarily a technical problem. It is a data ownership problem with code attached.

Decide who owns what, match on stable identifiers, handle failure loudly, and give it an owner.

And before any of that, ask honestly whether the second system needs to exist at all.