.png)
Odoo Inventory Integration Guide
Integrate Odoo Inventory with enterprise applications through Odoo’s JSON-2, JSON-RPC, and XML-RPC APIs, configured webhooks, scheduled workflows, and batch files.
Odoo Inventory integration options at a glance
Odoo Inventory integrations typically use Odoo’s model-oriented JSON-2 HTTP API, with JSON-RPC and XML-RPC remaining relevant for earlier versions and deployments. Odoo supports API-key authentication, while older integrations may require a database name, user, and password or API key. Configured webhook automations can support selected Inventory events, but broader change detection usually requires scheduled polling using timestamps, IDs, states, and domain filters. Odoo also supports CSV and spreadsheet-compatible import and export for batch processing, plus model-based access to attachments. Martini can consume these endpoints, receive webhook requests, schedule incremental synchronization, transform model responses, and apply validation, routing, retries, and error handling.
| Integration point | Supported by Odoo Inventory? | Common use cases | How Martini supports it |
|---|---|---|---|
| JSON-2 HTTP API | Yes | Odoo’s newer API exposes model methods through HTTP and can support reads and writes for products, warehouses, locations, transfers, moves, quantities, and related models. | Martini can consume the HTTP API from workflows, supply model arguments and field selections, map responses, and expose normalized APIs for downstream applications. |
| JSON-RPC APIs | Limited | Earlier Odoo versions commonly expose JSON-RPC through the /jsonrpc endpoint for model-oriented external operations. | Martini can call JSON-RPC endpoints, transform request and response envelopes, and route version-specific behavior through reusable workflow logic. |
| XML-RPC APIs | Legacy | Older Odoo integrations use /xmlrpc/2/common for authentication and /xmlrpc/2/object for model methods such as search, read, search_read, create, write, and unlink. | Martini can consume XML-based API responses and requests, apply XML processing, and preserve a version-compatible integration where XML-RPC is required. |
| Webhooks and outbound callbacks | Limited | Odoo Studio and supported automation features can invoke webhook-style integrations for selected configured business events. Coverage is not universal for every Inventory change. | Martini can receive configured webhook requests, validate their contents, retrieve the current Odoo resource, and process the event idempotently. |
| Bulk and batch processing | Limited | Odoo model methods can process lists of records, and import workflows support larger CSV or spreadsheet-based loads. No universal asynchronous bulk job service should be assumed. | Martini can partition requests, control concurrency, process batches, checkpoint progress, and handle partial failures through workflow error paths. |
| CSV and spreadsheet import/export | Yes | Files can support initial product and location loads, bulk updates, inventory reconciliation, and exchange with systems lacking a suitable API. | Martini can receive or generate files, validate rows, map columns to Odoo models, and produce exception or reconciliation outputs. |
| File and attachment models | Limited | The ir.attachment model provides access to files associated with Odoo records, subject to permissions and record relationships. | Martini can call the relevant Odoo model APIs, transform attachment metadata or content, and route files to approved downstream systems. |
| Authentication | Yes | Odoo supports API keys, including bearer-style credentials for JSON-2, while older APIs may use a database name, user, and password or API key. | Martini can store credentials in environment secrets and apply the required authentication configuration without embedding secrets in workflows or API definitions. |
How Odoo Inventory exposes data and business events
Odoo JSON-2 APIs
Odoo’s current documentation describes a JSON-2 HTTP API that exposes model methods and accepts the fields and arguments required by the target model. Availability and exact behavior depend on the Odoo major version, deployment, edition, and installed modules.
Martini implementation pattern
Martini implementation pattern: Martini consumes the Odoo HTTP endpoint from a workflow, authenticates with an API key stored as a secret, submits a bounded model query or operation, and maps the response into a canonical structure. The workflow can apply company, warehouse, permission, and business validation rules before writing to another system.
Implementation sequence
Odoo JSON-RPC and XML-RPC
Earlier Odoo versions commonly expose JSON-RPC and XML-RPC. XML-RPC uses the common endpoint for authentication and the object endpoint for model methods such as search, read, search_read, create, write, and unlink.
Martini implementation pattern
Martini implementation pattern: Martini selects the protocol required by the customer’s Odoo version, constructs the appropriate request envelope, and processes JSON or XML responses. Reusable workflow logic can isolate version-specific authentication and method invocation while keeping mappings and business rules consistent.
Implementation sequence
Odoo Webhook Automation
Odoo Studio and supported automation features can send webhook-style requests for selected configured business processes. These notifications are event- and configuration-dependent and do not constitute a universal stream for every Inventory change.
Martini implementation pattern
Martini implementation pattern: Martini exposes or consumes the configured webhook endpoint, validates the notification, and retrieves the current Odoo record when the payload is only a signal. The workflow checks the event against a stored external reference and routes unsupported or incomplete events to an operational error path.
Implementation sequence
Scheduled Odoo Synchronization
Scheduled polling is appropriate when the required Inventory event is not available through configured automation. Odoo data can be queried with write_date, record IDs, state fields, domains, bounded date ranges, and stable ordering.
Martini implementation pattern
Martini implementation pattern: A scheduled workflow maintains a checkpoint and queries only records changed after an overlap window. It pages through results, maps each object, writes to the target, and advances the checkpoint only after successful processing so transient failures can be retried safely.
Implementation sequence
Odoo File Import and Export
Odoo supports CSV and spreadsheet-compatible imports and exports for initial loads, bulk updates, inventory reconciliation, and exchanges with systems that do not provide a suitable API. File processing is a batch mechanism rather than a real-time inventory feed.
Martini implementation pattern
Martini implementation pattern: Martini receives or generates a file, validates headers and rows, maps product and location references, and submits approved data through the appropriate Odoo business process. Invalid rows are separated into an exception report rather than silently changing inventory.
Implementation sequence
Common Odoo Inventory integration patterns
Pattern 1: Synchronize inventory availability to a commerce platform
When to use this pattern
Use this pattern when Shopify, Magento / Adobe Commerce, WooCommerce, or another storefront needs current product availability from Odoo Inventory. The integration should distinguish on-hand, reserved, and forecast quantities rather than treating every stock value as immediately sellable.
Integration direction
Example Mapping
| Odoo Inventory Field | Canonical Field | Target Field |
|---|---|---|
| product.product.default_code | productSku | Shopify SKU |
| product.product.name | productName | Shopify product title |
| stock.quant.quantity | onHandQuantity | Shopify inventory quantity |
| stock.quant.reserved_quantity | reservedQuantity | Availability rule input |
Martini implementation pattern
A scheduled Martini workflow queries product.product and stock.quant with warehouse and location filters, calculates the publishable quantity using configured business rules, and updates the commerce platform. It uses an overlap window, stable identifiers, bounded concurrency, and retry handling for transient API failures. Unknown SKUs or ambiguous warehouse mappings are routed to an exception path.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- pagination
- error handling
- retry processing
Pattern 2: Send deliveries to a shipping platform
When to use this pattern
Use this pattern when completed or ready-to-process Odoo deliveries must be sent to ShipStation or another transportation application, with tracking information returned to Odoo. It is suitable for webhook-enabled events or scheduled polling of stock.picking.
Integration direction
Example Mapping
| Odoo Inventory Field | Canonical Field | Target Field |
|---|---|---|
| stock.picking.name | shipmentReference | ShipStation order or shipment reference |
| stock.picking.partner_id | recipient | Ship-to customer |
| stock.move.product_uom_qty | lineQuantity | Shipment line quantity |
| stock.picking.state | fulfillmentStatus | Shipment status |
Martini implementation pattern
Martini receives a configured Odoo notification or polls stock.picking by state and write_date, retrieves related move lines when required, and maps the delivery into the shipping platform’s model. Before creation, it checks the Odoo picking reference or stored synchronization key. Tracking responses are routed back through a separate workflow and written only to approved Odoo fields.
Martini capabilities used
- webhook consumption
- scheduled workflows
- API orchestration
- data mapping
- idempotency rules
- conditional routing
- error handling
Pattern 3: Publish normalized availability through an API façade
When to use this pattern
Use this pattern when Salesforce, an order-management application, or a customer portal needs a stable availability interface without depending directly on Odoo model names and version-specific structures.
Integration direction
Example Mapping
| Odoo Inventory Field | Canonical Field | Target Field |
|---|---|---|
| product.product.id | productId | Availability API productId |
| product.product.default_code | sku | Availability API sku |
| stock.warehouse.id | warehouseId | Availability API warehouseId |
| stock.quant.quantity | availableQuantity | Availability API availableQuantity |
Martini implementation pattern
Martini exposes a controlled API that accepts product and warehouse criteria, retrieves the necessary Odoo models, and returns a normalized response. The workflow applies access controls, company and warehouse filters, quantity rules, and response caching or bounded retrieval where appropriate. Odoo-specific errors are translated into stable API responses for consumers.
Martini capabilities used
- API exposure
- API consumption
- workflow orchestration
- data transformation
- business rules
- security configuration
- error handling
Pattern 4: Reconcile warehouse counts from a file
When to use this pattern
Use this pattern for periodic warehouse counts or external reconciliation files when the source process cannot use Odoo’s APIs directly. Inventory adjustments should follow the appropriate Odoo business process rather than directly overwriting stored quantities.
Integration direction
Example Mapping
| Odoo Inventory Field | Canonical Field | Target Field |
|---|---|---|
| count_file.sku | productSku | product.product.default_code |
| count_file.location_code | locationReference | stock.location |
| count_file.counted_quantity | countedQuantity | Inventory adjustment quantity |
| count_file.count_timestamp | countTimestamp | Reconciliation audit field |
Martini implementation pattern
Martini receives the CSV or spreadsheet, validates product and location references, compares counted quantities with the relevant Odoo quantities, and creates a reconciliation result. Approved discrepancies are passed into the customer’s defined Odoo adjustment or warehouse process, while invalid rows and conflicts are reported without changing inventory.
Martini capabilities used
- file processing
- scheduled workflows
- data mapping
- validation
- business rules
- exception reporting
- API consumption
Applications commonly integrated with Odoo Inventory
Odoo Inventory can be integrated with commerce, fulfillment, sales, finance, and enterprise applications when product, availability, order, shipment, or accounting data must move between systems. The exact scope depends on the Odoo version, installed modules, deployment model, and the target application’s APIs.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Synchronize products, inventory availability, orders, and fulfillment status between Odoo Inventory and an online storefront. | Shopify → Martini → Odoo Inventory | Martini can receive Shopify order events or poll the Shopify API, map products and orders to Odoo model structures, and use Odoo APIs for product, stock, and fulfillment operations. A reverse workflow can publish selected Odoo availability and shipment updates to Shopify with external references for idempotency. |
| Magento / Adobe Commerce | Coordinate catalog data, stock availability, orders, and shipment status for larger commerce deployments. | Magento / Adobe Commerce → Martini → Odoo Inventory | Scheduled or event-driven Martini workflows can retrieve commerce orders, validate product identifiers and warehouse context, and call Odoo model methods. Separate incremental workflows can publish stock quantities and picking status, while retries and stored external IDs prevent duplicate transactions. |
| WooCommerce | Send product and inventory data to a WordPress-based store and import customer orders into Odoo Inventory. | WooCommerce → Martini → Odoo Inventory | Martini can consume WooCommerce APIs and webhooks, normalize order and product payloads, and map them to Odoo products, pickings, and related records. Validation rules can reject unknown products or locations before a controlled Odoo write operation. |
| Amazon Marketplace | Synchronize marketplace orders, fulfillment status, and inventory quantities across marketplace and warehouse operations. | Amazon Marketplace → Martini → Odoo Inventory | Martini can orchestrate scheduled Amazon API retrieval and selected outbound updates, transform marketplace identifiers into Odoo references, and route fulfillment events to the appropriate warehouse or picking process. Checkpoints, bounded concurrency, and duplicate detection support operational reliability. |
| Salesforce | Expose inventory availability and fulfillment information to sales teams while synchronizing selected customer or order context. | Salesforce → Martini → Odoo Inventory | Martini can expose a normalized availability API backed by Odoo product, warehouse, location, and quant data. A separate workflow can receive Salesforce requests or events, apply company and warehouse rules, and retrieve or submit selected order-related information through Odoo APIs. |
| ShipStation | Transfer shipment details and delivery information while returning carrier tracking and fulfillment updates to Odoo. | Odoo Inventory → Martini → ShipStation | Martini can poll Odoo stock.picking records or receive configured automation notifications, map delivery details to ShipStation, and process tracking updates back into the appropriate Odoo workflow. Stable shipment references and idempotent writes prevent duplicate shipment records. |
| NetSuite | Coordinate inventory, fulfillment, product, or financial master data when Odoo and NetSuite coexist during consolidation or specialized operations. | Odoo Inventory → Martini → NetSuite | Martini can establish explicit ownership by data domain, retrieve Odoo model data and NetSuite records through their APIs, and transform identifiers, companies, warehouses, and statuses through canonical mappings. Business rules determine which system may create or update each object. |
| QuickBooks Online | Transfer product, customer, order, or inventory-related financial information while Odoo remains the operational inventory system. | Odoo Inventory → Martini → QuickBooks Online | A scheduled Martini workflow can extract approved Odoo operational transactions, map them to QuickBooks Online accounting structures, and record source IDs and response messages. Reverse synchronization should be limited to explicitly owned fields and defined accounting processes. |
How to build a Odoo Inventory integration in Martini
Objective
Confirm the Odoo version, deployment model, database context, API protocol, installed modules, and integration user permissions before building the workflow.
Instructions in Martini
- Choose JSON-2, JSON-RPC, or XML-RPC for the target Odoo environment
- Create or identify a dedicated Odoo integration user with minimum required permissions
- Store the API key or other credentials in Martini environment secrets
- Configure the endpoint, database name where required, timeout, and request settings
Objective
Select an event-driven or scheduled trigger based on the availability and completeness of Odoo automation events for the required Inventory process.
Instructions in Martini
- Use a configured Odoo webhook for supported selected events
- Use a scheduler when changes must be detected through polling
- Define the write_date, ID, state, domain, and overlap-window strategy
- Store a checkpoint that advances only after successful processing
Objective
Retrieve only the Odoo models, fields, and records required for the business process while preserving warehouse, company, and location context.
Instructions in Martini
- Query product.template, product.product, stock.quant, stock.picking, stock.move, or related models as required
- Use explicit field lists, domains, bounded date ranges, stable ordering, and pagination
- Retrieve related move lines or attachments only when needed
- Capture Odoo IDs, external references, statuses, and response messages
Objective
Coordinate the end-to-end exchange through a Martini workflow that separates transport, transformation, business rules, target writes, and operational failure paths.
Instructions in Martini
- Route webhook, scheduled, and batch inputs into reusable workflow logic
- Separate version-specific Odoo protocol handling from common mappings
- Apply company, warehouse, location, status, and ownership rules
- Branch validation failures and transient transport failures into appropriate paths
Objective
Convert Odoo model-oriented responses into the canonical and target-specific structures required by downstream applications or files.
Instructions in Martini
- Map product, quantity, movement, picking, and location identifiers
- Distinguish on-hand, reserved, forecast, moved, and delivered quantities where relevant
- Normalize dates, timestamps, statuses, units, and references
- Validate required fields and produce exception details for invalid data
Objective
Create or update downstream records and, where required, invoke supported Odoo business operations without bypassing Odoo’s inventory controls.
Instructions in Martini
- Check external references or synchronization keys before creating records
- Write commerce, shipping, CRM, finance, or reporting data through their supported APIs
- Use Odoo’s supported operations for receipts, deliveries, transfers, and adjustments
- Record target responses and Odoo IDs for reconciliation
Common Odoo Inventory data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| product.template | Stores product templates and shared product attributes used across product variants. | Shopify, Magento / Adobe Commerce, WooCommerce, Salesforce, NetSuite | Martini retrieves selected fields, maps product attributes to a canonical product model, validates required identifiers, and synchronizes only the fields owned by the integration. |
| product.product | Represents product variants and stockable product records used in inventory operations. | Shopify, Amazon Marketplace, WooCommerce, NetSuite | Martini uses stable Odoo IDs or external references, maps variants to target SKUs, and applies product and company rules before creating or updating downstream items. |
| stock.warehouse | Defines warehouse configuration and operational context for inventory processing. | Salesforce, commerce platforms, transportation platforms, reporting stores | Martini filters warehouse context explicitly, maps warehouse identifiers to target locations, and prevents data from an unintended company or operating unit from being published. |
| stock.location | Represents internal, transit, supplier, customer, and virtual stock locations. | Warehouse applications, commerce platforms, reporting stores | Martini resolves location IDs and usage types, applies location-specific availability rules, and retains mappings for incremental synchronization. |
| stock.picking | Represents inventory transfers such as receipts, deliveries, and internal transfers. | ShipStation, Shopify, Salesforce, NetSuite, transportation platforms | Martini polls or receives selected automation events, maps picking states and references, and uses idempotency checks before sending or updating fulfillment data. |
| stock.move | Represents planned or completed movement of products between locations. | NetSuite, warehouse applications, reporting stores | Martini distinguishes movement status and product quantities, enriches records with warehouse context, and applies business rules before downstream publication. |
Authentication and security considerations
Authentication and access control
Odoo API calls execute with the permissions of the authenticated user. API keys are supported, including bearer-style authentication for the newer JSON-2 API, while older XML-RPC and JSON-RPC integrations may require a database name, user, and password or API key.
- Use a dedicated Odoo integration user with minimum permissions.
- Restrict access to the required companies, warehouses, locations, products, transfers, quantities, lots, and attachments.
- Store API keys and other credentials in Martini environment secrets.
- Confirm record rules and custom modules before relying on a model or field.
- Do not assume OAuth is available for the core Odoo Inventory API.
Operational considerations for Odoo Inventory integrations
Version and deployment differences
Confirm the Odoo major version, Odoo Online, Odoo.sh, or self-hosted deployment, installed modules, subscription, and available external API before implementation. Model fields, methods, permissions, and webhook behavior can vary.
Reliable synchronization
- Use domains, explicit fields, bounded ranges, stable ordering, and pagination for large queries.
- Use checkpoints with an overlap window and idempotent external references.
- Apply bounded concurrency, timeouts, retry backoff, and handling for transient throttling or HTTP 429 responses where applicable.
- Define whether stock.quant, stock.move, stock.move.line, or stock.picking is authoritative for each use case.
- Account for reservations, concurrent operations, time zones, status transitions, and multi-company or multi-warehouse data.
- Test custom fields, required values, relational fields, computed fields, and selection values in the target environment.
Why use Martini instead of scripts or point-to-point integrations?
More than a point-to-point script
Martini provides a maintainable integration boundary between Odoo’s version-specific model APIs and downstream applications. Workflows can combine API calls, webhook handling, scheduled polling, file processing, transformations, business rules, and controlled writes without duplicating orchestration logic in every application.
- Centralize authentication, secrets, mappings, validation, and error handling.
- Expose a normalized API so consumers do not depend directly on Odoo model structures.
- Reuse integration assets across products, warehouses, pickings, and target systems.
- Support real-time-style webhook processing alongside scheduled and batch synchronization.
- Preserve checkpoints, response identifiers, logs, and exception paths for operational support.
- Extend workflows with custom JVM-compatible logic when standard transformations are insufficient.
Frequently asked questions
Odoo Inventory can be integrated through its JSON-2 HTTP API, earlier JSON-RPC or XML-RPC APIs, configured webhook automations for selected events, and CSV or spreadsheet-based batch exchanges. Scheduled polling is commonly used when an appropriate Inventory event is not available. The exact approach depends on the Odoo version, deployment model, installed modules, and required data objects.
Yes. Martini can integrate with Odoo Inventory by consuming Odoo’s JSON-2, JSON-RPC, or XML-RPC endpoints, receiving configured webhook requests, processing CSV or spreadsheet files, and orchestrating scheduled synchronization workflows. Martini can map Odoo models such as product.product, stock.quant, stock.move, and stock.picking into downstream application formats.
No. A dedicated Odoo Inventory connector is not required. Martini can use Odoo’s confirmed native integration mechanisms, including JSON-2, JSON-RPC, XML-RPC, configured webhooks, file imports and exports, and API-key-based authentication. No native Martini Odoo connector is documented in the supplied materials.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Odoo Inventory with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Odoo, hosting providers, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
For current Odoo deployments, evaluate the documented JSON-2 HTTP API first. JSON-RPC and XML-RPC remain relevant for earlier versions or compatible environments. Use configured webhooks for selected supported events, scheduled polling for broader change detection, and CSV or spreadsheet files for batch loads and reconciliation. GraphQL and SOAP APIs for Odoo Inventory are not confirmed in the supplied research.
Odoo supports webhook-triggered automation for selected configured business processes, but it should not be treated as a universal event stream for every product, quantity, move, or transfer change. Martini can receive configured webhook requests and retrieve the current resource, while scheduled polling using write_date, IDs, states, and domains can cover events that are not exposed.
Martini can query Odoo using explicit fields, domains, pagination, stable ordering, and an overlap-based checkpoint, then map model-oriented data into a canonical target structure. The workflow can distinguish stock.quant quantities from stock.move movements and stock.picking operational transfers, apply company and warehouse rules, and use Odoo IDs or external references for idempotency.
Martini workflows can separate authentication, permission, validation, business, serialization, and transport failures. They can retry transient errors with bounded concurrency and backoff, preserve checkpoints until processing succeeds, and use Odoo IDs or external synchronization keys to avoid duplicate creates. Odoo response messages and identifiers can be retained for troubleshooting and reconciliation.
Related Martini documentation
Workflows
Build a reliable Odoo Inventory integration with Martini
Use Martini to connect Odoo Inventory APIs, configured webhooks, scheduled synchronization, and batch files with the enterprise applications that depend on accurate product, warehouse, transfer, and stock data.