Eshop integration with Odoo: workflows, prerequisites and testing

Integrate the store with Odoo around a defined workflow and the installation's available interface. An Odoo integration follows the database actual models, product variants and units of measure. The connector must not rely on a fixed schema assuming identical custom fields in every installation.

An Odoo integration follows the database actual models, product variants and units of measure. The connector must not rely on a fixed schema assuming identical custom fields in every installation. Record the data needed for catalogue, customer and order, and the business step confirming a purchase. Check upgrades or module changes against representative records, particularly where bundles, quantity conversions or additional sales customisation are involved.

Odoo 19 introduces an external JSON-2 API over HTTP with an API key. Available models, fields, and methods depend on the particular database and appear in its dynamic documentation. Hosted external API access requires the Custom pricing plan. Standard and One App Free hosted plans do not provide the same external API access. Older versions can expose a different interface. We do not assume a custom model exists in every Odoo installation.

A food business sells individual units and cartons of the same product. The store retains variant identifier and purchase unit, while mapping defines their equivalents in Odoo. One carton must not become one item or undergo quantity conversion twice. The order follows the agreed business operation so that subsequent steps remain within the application workflow. If a custom field changes, testing reveals incompatibility before production transactions are transferred.

An important failure scenario occurs when a custom field changes and the order payload no longer matches the database schema. Keep the external reference and confirmed destination ID before retrying. Separate access failure, business rejection and an unknown outcome. An operator must be able to inspect the relevant record and resolve its status without replaying completed steps. Agree which fields may appear in logs and who handles unresolved cases.

Test a product variant, a different unit of measure, and a custom-field change in testing. For each case record the expected source data, destination record and customer-visible state. Include one denied-permission case and one interrupted response. Re-run a previously confirmed event and check that its business effect is unchanged. The acceptance record should identify the responsible team and the evidence required to close any discrepancy.

The initial discovery should confirm: Odoo version and permitted API access/plan; Least-privilege API key; Dynamic documentation of actual models and modules. Before launch, document the mapping for Models/schema → agreed mapping → Catalogue and variants → online store → Order → Odoo business confirmation. Assign responsibility for access renewal, monitoring and correction. A change to product configuration or the agreed business rule should trigger targeted regression checks. Begin with this defined workflow; add another channel only after its ownership and acceptance cases are clear.