Odoo API integration design: ownership, identity, and failures

Reliable Odoo integrations define the system of record, stable identifiers, event timing, duplicate handling, retries, and operational ownership before coding.

An integration is a shared operating process, not only an API call. It must remain correct when records change, requests arrive twice, one system is unavailable, or a user corrects data manually. Assign field ownership For each shared field, decide which system can create and update it. Customer email may originate in ecommerce while credit limits belong to Odoo. Without ownership rules, systems overwrite one another and users stop trusting both. Use stable external identities Names, emails, and SKUs can change or collide. Store durable source identifiers and mapping records. Define how merges, deletions, and recreated records affect those mappings. Design for repeated and late events Networks retry, webhooks arrive out of order, and batch jobs overlap. Processing should be idempotent where possible. The integration needs checkpoints or event versions so an older update does not replace newer information. Make failure operational Record the source reference, action, timestamp, payload context, exact error, retry count, and responsible team. Users need a safe retry or resolution path without asking a developer to search server logs. Practical checklist Create a field-level system-of-record matrix. Use external IDs rather than names as matching keys. Define create, update, cancel, delete, and merge behaviour. Make duplicate processing safe and retries controlled. Expose failures with context, ownership, and monitoring. Final decision The happy path proves connectivity. The failure model proves whether the integration can support daily business without silent corruption or permanent developer supervision.