/services/odoo-integration
Connect Odoo to the systems you're keeping.
Payment gateways, marketplaces, shipping, banks and legacy databases — built with retry, reconciliation and a defined behaviour for every failure.
- 2-way sync where the data demands it
- 100% integrations with a defined failure behaviour
- 14 countries served
Facts. - 2-way · sync where the data demands it - 100% · integrations with a defined failure behaviour - 14 · countries served
/the-problem
Integrations don't fail loudly. That's the problem.
An integration that breaks visibly gets fixed on the day. The expensive ones are the quiet failures — a nightly sync that has been skipping records for three weeks, a payment webhook that silently dropped four transactions, a stock feed that stopped and left the marketplace selling what you no longer hold.
By the time anyone notices, the reconciliation is archaeology. And it is almost never the happy path that broke. It is the timeout, the duplicate, the record that arrived out of order, or the field the other system started sending as null.
So we build the failure behaviour first. What happens on a timeout, what happens to a duplicate, where a rejected record goes, and who finds out. If an integration can fail without anyone being told, it is not finished.
/what-every-integration-includes
What every integration includes
- Payment gateways and local acquirers
- eCommerce platforms and online marketplaces
- Shipping, courier and freight-forwarder systems
- Banks, for statement import and reconciliation
- Legacy databases you aren't replacing yet
- Warehouse hardware — scanners, scales, label printers
- Anything with a documented API, and several things without one
- A defined behaviour for every failure mode, written down
- Retry with backoff, not a silent drop
- A rejected-record queue somebody actually looks at
- Reconciliation you can run on demand, not only on schedule
- Alerting that reaches a person, not a log file
- Credentials held in configuration, never in code
/how-we-run-it
Five stages. Stage two is the one that gets skipped elsewhere.
A single well-documented API integration runs two to four weeks. Legacy systems without documentation, or anything touching money, take longer — and should.
-
01
Discovery
What moves, in which direction, how often, and what the system of record is for each field.
2–4 days
-
02
Failure design
Every failure mode listed with a defined behaviour. Signed off before anything is built.
2–3 days
-
03
Build
Developed against a sandbox where one exists, with logging from the first commit.
1–3 weeks
-
04
Reconciliation testing
Run against real volumes, including the deliberately broken cases.
3–5 days
-
05
Cutover & monitoring
Live with alerting in place, watched closely for the first fortnight.
1 week
/what-you-get
Four artefacts you keep.
Integrations are the part of a system most likely to be understood by exactly one person. These exist so that person isn't the only one.
Data flow map
what moves where, how often, and which system owns each field.
/02Failure matrix
every failure mode, its defined behaviour, and who gets told.
/03The code, in your repository
with its credentials in configuration, never hard-coded.
/04Reconciliation procedure
how to check the two systems agree, runnable by your team without us.
/where-this-fits
What comes before this, and what comes after.
Integration usually follows implementation and sits alongside customisation. Consulting decides what should be integrated versus replaced — a question worth asking, because the cheapest integration is often the one you don't build.
/questions
Asked on every first call.
-
Often, yes — through a database connection, a file exchange or, as a last resort, screen automation. But we'll tell you honestly where that lands on the fragility scale. A file-based integration that runs nightly is a different proposition from a real-time API, and the difference should shape what you build on top of it.
-
Whatever we agreed at stage two. Usually: retry with backoff, queue what can't be delivered, alert a person after a defined threshold, and never silently drop. The specific behaviour is in your failure matrix, because the right answer differs between a stock update and a payment.
-
You do — the code is in your repository. Under an AMC we monitor it, and integration failures are one of the things we'd rather tell you about than have you discover.
-
Whichever fits. XML-RPC is the mature, well-documented route and it's what most integrations still use. Where a third party expects REST and webhooks, we build that. The choice is a technical detail, not something you should have to have an opinion about.
-
Sometimes. Often a scheduled action and a well-configured connector reach it, and occasionally the answer is that the data shouldn't be integrated at all — it should live in one system. That's the standard-first test, applied to integration rather than customisation.
/next
Tell us what breaks between systems today.
Thirty minutes, no slides. We will tell you straight if Odoo is not the answer.