Odoo integration planning: ownership, sync rules, and recovery

Define the business contract between systems

For every object, name its authoritative source and the direction of movement. A customer record may originate in one application while payment status originates in another. If both systems can edit the same field, specify the conflict rule before building the connection.

Choose the required frequency based on business consequences. An hourly update may be sufficient for a management report but unsuitable for a stock availability promise. Document acceptable delay, transaction volume, peak load, and the people who will respond when records stop flowing.

Test the interface against the exact deployment

Odoo 19 introduces the JSON-2 API, and API operations follow the connected user's access permissions. Existing connectors may target different interfaces or versions. Verify compatibility and the current subscription requirements instead of assuming every connector works with every deployment.

Request a written field map and a demonstration with representative records. Include discounts, returns, cancellations, partial fulfilments, renamed products, and any multi-company boundary. Compatibility is more than a successful connection screen.

Design for failures before launch

• Stable keys: identify the same record consistently across both systems.
• Duplicate prevention: define what happens if a delivery is retried.
• Validation: reject or hold incomplete records without silently losing them.
• Retry rules: distinguish temporary outages from permanent data errors.
• Monitoring: show the last successful sync, failures, and unprocessed work.
• Reconciliation: compare counts and business totals, not only request success codes.
• Recovery: allow an authorized operator to resolve and replay failed work safely.

Make access and maintenance explicit

Use dedicated integration identities with only the permissions needed. Keep credentials on the server side in an approved secret store, define rotation and revocation, and avoid writing secrets or unnecessary personal data to logs. Confirm who can see integration logs and how long they are retained.

Agree on ownership when either system changes. Record the deployed version, source-code location where applicable, monitoring destination, dependency list, and support procedure. Test the interface again after upgrades and before relying on new fields or transaction types.

Example: recover an order without creating two

An external store sends an order, but the connection times out before receiving confirmation. The receiving system may have already created the order. If the sender retries without a stable transaction identifier, the business could receive a duplicate. Define how the connection checks whether that transaction already exists before attempting another creation.

Test the same scenario during acceptance, including the operator view of the failure. The team should be able to identify the affected order, see whether it was processed, and complete recovery without guessing. Repeat the test for a rejected product code so temporary technical faults and permanent data errors have different handling.