Odoo, connected to the rest of what you run
Almost nobody runs on one system. The cost of that shows up as the same order being typed into three places, and as two systems quietly disagreeing about stock until someone notices in a stock count. We connect Odoo to what is around it so a record is entered once, and we build for the morning the other end is down, because that morning arrives.
- Order #1042SO0431Synced
- Payment 2,480BNK1/0098No answerSynced
- Stock 24 unitsWH/StockSynced
What we connect
Shops and marketplaces
Orders, stock, prices and fulfilment moving between Odoo and Shopify, WooCommerce, a marketplace or your own storefront, so the shop and the warehouse hold the same number.
Payments and banks
Gateways, bank feeds and payment files, so a receipt lands against the right invoice without somebody matching it line by line.
Accounting and tax systems
QuickBooks, Xero and the e‑invoicing or fiscal reporting your country requires, whether Odoo is the system of record or the one being fed.
Carriers and logistics
Rates, labels, tracking and proof of delivery, so a customer asking where their order is gets an answer out of the system rather than out of a person.
Your own systems
The backend, portal or legacy database the business already depends on, connected over Odoo’s external API instead of being replaced on a timetable nobody agreed to.
Reporting and data
Odoo data pushed to where your analysts already work, so nobody starts Monday by exporting spreadsheets.
Systems we connect Odoo to
The marks below are the systems this kind of work usually involves. If yours is not here, ask: what decides whether a connection is straightforward is whether the other side has a documented way in, not whether we have met it before.
Payments
- Stripe
- PayPal
- Adyen
- Razorpay
- Mercado Pago
- SumUp
- Pix
eCommerce & Marketplaces
- Shopify
- WooCommerce
- Salla
Shipping & Logistics
- FedEx
- UPS
- DHL
- USPS
Accounting & Legacy Systems
- QuickBooks
- Xero
- Sage
- SAP
- Avalara
CRM, Marketing & Communication
- Gmail
- Google Calendar
- HubSpot
- MailChimp
- Meta
- Google Ads
- Zoom
Data & Reporting
- Looker
- Google Sheets
All trademarks and logos belong to their respective owners.
What we build for the day it breaks
Every integration works on the afternoon it is demonstrated. The difference between one that is still trusted a year later and one everybody has quietly stopped believing is entirely in what happens when something goes wrong.
The same message twice does nothing twice
Retries, double clicks and replayed queues all send the same thing again. Every write is keyed on something stable from the source, so arriving twice produces one record, not two.
Failures retry, then stop and say so
A system being down for an hour should cost you nothing. Calls back off and retry, and when they genuinely cannot succeed they stop rather than hammering a service that is already struggling.
Nothing fails silently
What cannot be retried lands in a queue a named person looks at, with the payload and the error attached. A failure nobody sees is worse than no integration, because the business has stopped checking.
The mapping is written down
Which field becomes which, which side owns the master value, and what happens when they disagree. This is the document that stops an argument eighteen months from now.
Both sides get counted
A scheduled reconciliation compares the two systems and reports the difference, so a slow drift is caught in a day rather than at year end by your auditor.
Someone is told
Alerts go to a person who can act, not to a shared mailbox. We agree who that is before go‑live, because afterwards it becomes nobody.
Connected for clients
Subscription energy, Brazil
Odoo connected to the Rails backend the business already ran on, alongside recurring billing and Brazilian tax compliance.
Sales, Accounting, CRM, Project, Helpdesk
Furniture retail, São Paulo, Brazil
NF‑e and NFC‑e issued through Avalara, with CNAB240 and PIX payments, across stores and ecommerce.
Point of Sale, Inventory, Accounting, Sales, Purchase
Read the case study
Reserved
Four or five client videos, two to three minutes each, still to be recorded. A video about one client becomes that client’s card above: the still behind it, a play button on it, and nothing fetched from YouTube until somebody presses play. The QuickBooks to Odoo middleware is the obvious subject for one of them: it is the only piece of work here that shows a connector built rather than configured, and it is the pairing most worth being found for.
What each video covers
- Both systems named in the first sentence, and in the video title. Someone who searched for “Odoo and QuickBooks” has to hear both words in the first ten seconds.
- What the business was doing before. The double entry, the spreadsheet, the person who re-keyed orders every morning.
- What moves now, in which direction, and how often.
- The screen rather than slides. One real record crossing is worth more than any diagram.
- What went wrong and what catches it. The argument of this whole page is the failure case, and almost nobody else puts that in a video.
- Nothing on screen the client has not cleared.
What comes back with it
- The link.
- The client, and whether they have agreed to be named.
- Which systems it covers, so the card links to the right marks on the wall.
- A summary or the transcript. Video cannot be watched here, and the words are needed for the page copy and for the markup that puts a thumbnail in search results.
- A still from the video, if the page is to stay free of external requests. Otherwise the thumbnail is one call to Google per card.
Common questions
Can we integrate if we are on Odoo Online?
Partly, and the detail matters. Odoo’s documentation states that access to data through the external API is only available on Custom pricing plans, and webhooks are set up in Studio, which is on that plan too. So an integration on Odoo Online is possible but it decides your plan, and Odoo Online will not run custom code, which means any middleware lives outside it. On Odoo.sh or your own server none of this applies. This is worth settling before the licence is bought, because afterwards it is an awkward conversation.
Do you build a connector or use an existing one?
We look for an existing one first and tell you honestly what it does not do. A connector someone else maintains is cheaper to buy and cheaper to keep, and the cases where building wins are narrower than they look. We build when the mapping is genuinely specific to your business, when the thing on the other side has no connector, or when a failed message costs enough that you need to own the retry logic rather than inherit it.
What happens when the other system goes down?
Nothing you have to deal with, if it was built properly. Messages queue and retry with a growing gap between attempts. What cannot be delivered ends up somewhere a person looks at, with enough detail to fix and replay it. The failure case is the part of an integration worth paying for; the happy path is the easy half.
How do you stop duplicate orders or double payments?
Every write is keyed on something stable from the source system, so the same message arriving twice updates one record rather than creating a second. This matters more than it sounds: retries, queue replays and impatient users all produce the same message twice, and an integration without this quietly fills your database with near duplicates that nobody can safely delete.
Which system wins when the two disagree?
That is a decision for your business, not for us, and it is one of the first things we make you make. For every field that exists on both sides, one system owns it and the other follows. Written down before anything is built, this is a short conversation. Discovered afterwards, it is a reconciliation project.
Can you connect something that has no API?
Often, but say so early. Depending on what it is, the route might be a database connection, a scheduled file exchange, or a vendor who will open an endpoint if asked by a paying customer. We have used all three. What we will not do is screen scrape something fragile and call it an integration, because that breaks the first time the other side changes a page.
How long does an integration take?
The build is rarely the long part. Agreeing what moves, in which direction, and who owns each field is the long part, and it is work your team has to do with us. A single well‑defined flow with a documented API on the other side is a short project. Several flows, two way, into something undocumented is not, and anyone quoting that without seeing the other system is guessing.
Other Odoo services
Build
Get Odoo in place and shaped to your business
Tell us what Odoo has to talk to
Name the system and what has to move between it and Odoo. We will tell you whether an existing connector covers it, what it would take to build, and where the work actually is, which is usually not the code.