7 Integration Mistakes That Corrupt Odoo Data

1. No ownership rule

The root cause behind most of the rest. Both systems can write the same field, nobody decided which one wins, and each write triggers the other to sync back.

Symptoms are maddening: a price that reverts overnight, an address that changes back after somebody edits it, two systems each behaving exactly as built.

Write the ownership map first. One row per shared field, one owner. Where both genuinely need to write, split the field rather than sharing it: the storefront owns the web description, Odoo owns the internal one.

2. Matching on email or name

Every duplicate-record problem traces back here. Email addresses change, get shared between a couple or a department, and are typed inconsistently. Names have three spellings and two genuine customers can share one.

Store the external system's identifier on the Odoo record and match on it. It is stable, unique and unambiguous.

This also buys idempotency, which is the next item, and it is the single highest-value decision on this list.

3. No idempotency

Messages arrive twice. Batches get re-run after a failure. A webhook sender that does not receive your acknowledgement in time sends again, by design.

An integration that creates on every message will duplicate. One that matches on an external id and updates will not, and that difference is what makes a failed run safe to replay.

Test it deliberately: send the same message twice and confirm you have one record. It takes a minute and it is the check nobody performs.

4. Calling an external system inside the save

An HTTP request in a create or write override makes the user wait for someone else's server, and a failure rolls back the record they were trying to save.

So a payment provider having a slow afternoon becomes your staff unable to confirm orders, and the error they see blames Odoo.

Queue the message and send it from a scheduled action. The record saves regardless, and the send retries on its own schedule. The same applies inbound: a controller receiving a webhook should verify, store and return quickly, then process afterwards, because senders time out and retry.

5. Integration credentials with administrator rights

Convenient during development and permanent afterwards. The integration user is an administrator, so nothing is ever blocked, and any compromise of those credentials reaches the entire database.

Create a dedicated user with the narrowest access that works. Not a person's account, which breaks when they leave, and not an administrator.

Two related habits. Odoo methods prefixed with an underscore are not callable over RPC, which is a deliberate security boundary rather than a naming convention, so an integration needing a public entry point should get a narrow one written for it. And OAuth grants should request the minimum scope each integration needs rather than one credential holding every permission.

6. Trusting the payload

Inbound data is external input. It will contain a currency you do not trade in, a country code that is not a country, a quantity with four decimal places on a product tracked in units, and eventually a null where the documentation promised a value.

Validate before writing. Reject clearly rather than coercing quietly, because a coerced value looks like real data forever afterwards.

This matters most where the wrong value is plausible. A malformed date fails loudly; a price silently rounded to two decimals on a product priced to four does not, and it becomes a margin discrepancy nobody can source.

7. Monitoring errors instead of silence

The failure that costs the most is not an error. It is a sync that stopped running: a credential expired, a webhook URL was regenerated, a scheduled action was disabled during an upgrade and never re-enabled.

Nothing errors, because nothing runs. An error-only alert is structurally incapable of seeing it.

Alert on absence: no successful run in the last N hours, no orders received today when there are always orders. That single alert catches more real incidents than every error handler combined.

The pattern underneath

Six of these seven are silent. They produce no traceback, no red banner and no log line saying something went wrong, which is exactly why they accumulate.

So the defences are structural rather than reactive: ownership decided in writing, matching on identifiers, idempotency tested rather than assumed, and monitoring that notices nothing happening. All four are decided during design, which is why integration architecture is worth the afternoon it takes.