Odoo Connector

Use this page when you need the Odoo-side setup details for the Odoo connector. For shared connector behavior, start with Connectors Overview and Provider Auth And Setup.

Runtime Shape

Implemented modes: live only
Auth strategies:
- user-managed API key entered by the signed-in web user
- company-managed deployment API key entered by a customer CMS operator
Live domain: business-record
Canonical tool id: business-record-live-query
Provider API: Odoo JSON-2 only, through /json/2/<model>/<method>
Credential profile key: odoo

Company-Managed Operator Setup

Odoo JSON-2 requires Odoo 19 or newer and Odoo external API access on a plan that includes it. Odoo documents external API access as unavailable on One App Free and Standard plans.
A customer CMS operator enters the Odoo URL and API key. For hosted *.odoo.com accounts, the database field is normally left blank so Odoo can route by URL/Host.
If Odoo asks the operator to connect to or choose a database, the operator can enter that database name during setup. Hosted values such as mycompany.odoo.com are normalized to the JSON-2 database token mycompany.
The optional model allowlist is an advanced limiter. Leave it blank for normal supported business-record coverage. Add only supported technical Odoo model names when an Odoo administrator wants to restrict which record types can be queried. It does not add new Odoo app coverage.
Payload stores only non-secret profile metadata and configuration. It does not store the raw API key.
Production customer-cluster installs store the key in Kubernetes Secret storage and mount that Secret into API as files.
Local development uses the same CMS entry and rotation flow, backed by gitignored files under env/cms-customer/connector-credentials/.
Rotation writes the inactive slot, validates it, and flips the active slot only after validation succeeds.
Setup and rotation save the Odoo URL, database, and model allowlist only after validation succeeds. A failed validation does not leave attempted setup values behind in Payload.
CMS operators can remove the company-managed Odoo API key profile. Removal clears saved key slots and setup fields; existing company-managed Odoo connectors in the web app become unavailable until an operator validates a new API key.
Existing web users do not reconnect after rotation because the deployment identity is server-side.

User-Managed API Key Setup

The signed-in web user enters their own Odoo URL, optional database, and API key in the web app.
API validates the key with Odoo JSON-2, encrypts it in API-owned user credential storage, and scopes it to that user’s connector record.
The credential is not stored in CMS and is not usable by other app users.
Business-record answers are limited by the Odoo user represented by that API key plus the connector’s supported model coverage.

Provider-Specific Gotchas

Odoo must have JSON-2 available.
Use a suitably permissioned Odoo user. For company-managed setup, that should be a service or bot user. The connector can only read models and fields that selected Odoo user can access.
Initial allowed models include partners, CRM leads, sales orders, POS orders, invoices/account moves, project tasks/projects, helpdesk tickets, products, stock pickings, purchase orders, manufacturing orders/BOMs, maintenance requests/equipment, events, and fleet vehicles.
HR employee/time-off/recruiting records, documents/knowledge content, discuss/messages, marketing-contact lists, and other app-specific private records are not in the default model set. Add those only after a separate privacy/domain decision and eval coverage.
Inaccessible or unavailable models should be skipped with coverage disclosure, not treated as complete inventory.
Custom fields and relationships should remain structured metadata in the business-record result shape.
There is no XML-RPC fallback, JSON-RPC fallback, write support, webhooks, indexed sync, Meltano tap, or embeddings path for Odoo.

Default App Coverage

The customer CMS advanced model field only restricts the supported set below. It does not add arbitrary Odoo models. Leave it blank unless an Odoo administrator wants a narrower read surface.

Odoo app area	Default technical models
Contacts / customers / vendors	`res.partner`
CRM	`crm.lead`
Sales / POS	`sale.order`, `pos.order`
Invoicing / accounting moves	`account.move`
Project / services	`project.task`, `project.project`, `helpdesk.ticket`
Products / inventory / purchasing	`product.template`, `stock.picking`, `purchase.order`
Manufacturing	`mrp.production`, `mrp.bom`
Maintenance / assets	`maintenance.request`, `maintenance.equipment`, `fleet.vehicle`
Events	`event.event`

Verification

Mocked adapter coverage should include /doc, search_read, detail, unavailable model, auth failure, timeout, and malformed payload.
Real-provider smoke uses:
- REAL_PROVIDER_E2E_ODOO_BASE_URL
- REAL_PROVIDER_E2E_ODOO_API_KEY
- optional REAL_PROVIDER_E2E_ODOO_DATABASE
Local prompt-pack checks can run with:

bun run chat:prompt-pack:run:local -- --connector odoo --domain business-record

Canonical Sources

packages/domain/src/connectors/connectorRegistry.ts
packages/connector-credentials/src/index.ts
apps/cms-customer/src/collections/ConnectorCredentialProfiles.ts
apps/api/src/connectors/odooJson2Client.ts
apps/api/src/connectors/odooBusinessRecordLiveAdapter.ts
apps/api/src/connectors/liveAccessBusinessRecordContracts.ts
infra/helm/customer-cluster/
docs/features/connectors/spec.md
docs/features/live-query/spec.md