The layer below the happy path.
What does an integration actually have to survive?
An integration has to survive partial failure. The remote system times out mid-write, returns a duplicate, changes a field type without notice, or comes back three hours later expecting the same request again. Handling the successful call is a morning’s work. Handling everything else is the engineering.
Most integrations are written once, against a sandbox, by someone who will not be there when it breaks. They pass acceptance because acceptance tests the happy path. Six months on, the finance team is reconciling by hand, someone has written a spreadsheet to catch the orders that didn’t sync, and nobody can say whether the mismatch is in the payment gateway, the ERP, or the retry that fired twice.
We build for the other days. Idempotency keys so a replayed webhook doesn’t double a payment. Reconciliation jobs that compare both sides on a schedule and raise the delta rather than silently absorbing it. Dead-letter handling, so a failed message is a queue you can inspect, not a log line that scrolled past. Twenty-plus integrations delivered across twelve-plus active geographies, and the ones we’re proudest of are the ones nobody has had to call us about.
Four domains, one discipline.
The failure modes rhyme. A payment gateway that double-posts and a meter feed that back-fills yesterday’s reads are the same problem wearing different clothes.
Banking & Finance
Bank connectivity, accounting sync, and statutory e-invoicing: the integrations where a mismatch is not a bug, it’s an audit finding.
Delivered: ICICI Banking (token, redeem, voucher hardening, reconciliation) · PowerOffice Go (end-to-end two-way sync, for a Norwegian partner) · Peppol e-invoicing
Payments
Ten payment gateways across India, Africa, the Gulf, and the Nordics. Nine of them are published as installable Odoo apps and maintained across versions. Built for markets where the gateway is regional and the documentation is thin.
Delivered: PhonePe · Cashfree · Paystack · Peach Payments · PayGate · HappyPay · PayJustNow · PayTabs · Mondido · Klarna
Logistics & Commerce
Order, status, and inventory sync across couriers, warehouse systems, and point-of-sale: the estate where one late webhook becomes a customer complaint.
Delivered: DelhiveryOne · Roboost · Logistra (WMS) · Ordable · Foodics · DHL (custom sample-dispatch integration)
Metering, Energy & Devices
Hardware and time-series feeds, where the data arrives late, out of order, or twice, and the ERP has to be right anyway.
Delivered: Nordpool (hourly area-based energy rates) · Elvaco (meter readings, measure points, hourly reads) · ZKTeco attendance devices · custom receipt and label printers
Eleven of these are installable, today.
Most consultancies describe integration work. Ours is on a public store: versioned, priced, supported, and source-available. Twenty-four Entrivis apps are published under “Entrivis Tech Pvt. Ltd.” Eleven are paid: ten payment gateways and DelhiveryOne, plus one free utility. You can install one this afternoon without speaking to us.
Eleven paid apps on the store — ten payment gateways and DelhiveryOne — plus one free utility. Version coverage is per module; check the listing.
Where it gets difficult.
Three integrations, three ways to lose money quietly. None of these were hard to connect. All of them were hard to trust.
Two-way accounting sync, Norway
A Norwegian accounting platform and Odoo, each authoritative on different fields, writing to each other in both directions. The API was a week. The question that took the project was: when the two disagree about a value, which one wins - and how would you know it happened? We wrote a reconciliation pass that compares both ledgers daily and raises the delta. It has never had to be run by hand.
PowerOffice Go · Peppol · end client under NDA
Energy rates and meter reads, Nordics
Hourly area-based rates from Nordpool. Meter readings and measure points from Elvaco. Both feeding an ERP that raises invoices on them. Time-series data arrives late, out of order, and sometimes twice. Billing does not accept “late” as an explanation. Ordering guarantees, back-fill handling, and idempotent writes were the architecture, not the remediation.
Nordpool · Elvaco
POS across three branches
One customer, three branches, a delivery platform and an Odoo POS estate that had to agree on products, categories, inventory, orders, and payments, simultaneously, all day. Plus a receipt printer speaking a protocol nobody had integrated before. The integration was the easy half. Deciding which system owned stock, per branch, was the project.
Ordable · custom printer integration
Twenty-plus integrations delivered across twelve-plus active geographies. Thirty-five percent of our team’s effort goes to work that happens after go-live, and integrations are where most of it lands.
What we won’t pretend.
An integration is a standing liability, not a deliverable. The remote API will change. The certificate will expire. The gateway will deprecate the endpoint with ninety days’ notice, on a Friday. Anyone who sells you an integration as a one-time build is selling you the first six months and none of the rest.
So we price it honestly. A build is a build. Keeping it alive is Managed Continuity, and we’d rather name that on the website than surprise you with it in year two. If you want the integration and not the relationship, take the published apps: they’re maintained, they’re cheap, and you owe us nothing.
We also say no. If your requirement is a single nightly CSV drop, you do not need integration engineering and we will tell you so. The discipline is worth paying for when the data is operations-critical, bidirectional, or reconciled against money. When it isn’t, we’ve just talked ourselves out of a project, which is roughly the point.
How we build one.
Every integration we ship runs the same five steps: a payment gateway and a metering feed get the same discipline. The order is the point: the decisions that sink an integration are made at the top, in the contract, and discovered at the bottom, in production. We move them forward.
-
01
Contract, before code
Both sides’ schemas, on paper. Which system is authoritative for each field, what a conflict means, and what happens when the answer is “both.” Most integration failures are decided here and discovered in production.
-
02
Failure modes, enumerated
Timeout, duplicate, out-of-order, partial write, silent schema change, credential expiry. Each one gets a written behaviour before anything is built. Unenumerated failure modes become incidents.
-
03
Build with replay in mind
Idempotency keys. Dead-letter queues you can inspect. Structured logs that name the transaction, not the function. Every write is assumed to arrive twice.
-
04
Reconcile on a schedule
A job compares both systems and raises the delta. It runs whether or not anyone is looking. This is the single control that separates an integration you trust from one you audit by spreadsheet.
-
05
Hand over the runbook
What alerts, who it wakes, how to replay a failed message, how to rotate the credential. Written down, in your repository. If we disappeared, your team could run it. That is the test.
Common questions about integration engineering
Do you only integrate with Odoo?
No. Odoo is where most of our work lands, because most of our clients run it. The engineering (reconciliation, idempotency, dead-letter handling) is platform-agnostic, and we’ve applied it against ERPNext and bespoke systems. If your ERP has an API and a sense of humour, we can work with it.
We already have an integration. It’s failing. Can you take it over?
Yes, and about a third of our clients came to us second. Start with Rescue & Stabilization: we audit what exists, tell you honestly what’s salvageable, and rebuild only what has to be rebuilt.
What does an integration cost to keep running?
Less than the build, and never zero. Remote APIs change, credentials expire, gateways deprecate endpoints. We cover this under Managed Continuity rather than pretending it doesn’t exist. See Engagement Models.
Can we just buy the app instead of hiring you?
For the ten payment gateways and DelhiveryOne, yes. They’re on the Odoo Apps Store, priced, versioned, and maintained. Install one and you owe us nothing further.
How many integrations have you delivered?
Twenty-plus, across twelve-plus active geographies: banking, payments, logistics, POS, energy metering, and hardware devices. Eleven paid apps are published as installable modules, which means you can verify a portion of that claim without asking us.
Who owns the code?
You do. It lives in your repository, with the runbook. We’ve never held a client’s integration hostage and we’re not going to start.
Tell us what’s supposed to reconcile.
Bring the two systems, the field that keeps disagreeing, and what it costs you when it does. We’ll tell you whether it’s an integration problem or a process one: those are not the same, and only one of them is ours to fix.