Odoo
ReviewAudited by ClawScan on May 15, 2026.
Overview
The artifacts describe a coherent Odoo connector, but it will act with your Odoo credentials, can automatically post or update configured Odoo records, and persists queued messages locally.
Before installing, treat this as a business-system integration with real Odoo authority: use a dedicated least-privilege Odoo API user, keep the webhook secret strong and private, restrict routes to safe methods, make custom methods idempotent, and secure the OpenClaw state directory and telemetry backend.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent reply can cause Odoo posts, updates, record creation, or custom method calls allowed by the configured route and Odoo user.
The plugin intentionally provides broad XML-RPC delivery into Odoo. This is disclosed and configurable, but misconfigured routes or overly privileged Odoo credentials could allow unintended business-record mutations.
the agent's output can flow back into Odoo as a chatter message, a newly created record, a field update, or anything else callable via XML-RPC
Use a dedicated least-privilege Odoo user, prefer narrow safe reply methods, review every configured route, and avoid routing agent output directly into destructive or non-idempotent methods.
The plugin can act as the configured Odoo user, and anyone with the webhook secret can submit inbound events to the gateway.
The plugin requires Odoo account authentication and a shared webhook bearer secret. This is expected for the integration, but it gives the plugin delegated Odoo authority.
"password": { "type": "string", "description": "Odoo API key or password for XML-RPC" },
"webhookSecret": {
"type": "string",
"description": "Shared secret for verifying inbound webhooks from Odoo (Bearer token)"Create a dedicated low-privilege Odoo API user, use HTTPS, generate a strong webhook secret, rotate secrets periodically, and restrict allowed sender users where possible.
Sensitive Odoo messages can be stored under the OpenClaw state directory and later replayed during retry or recovery.
Inbound Odoo content and generated replies are stored in a persistent local queue so they can be retried after crashes/restarts. This is disclosed reliability behavior, but it means business content may remain on disk.
The webhook handler persists each inbound message to disk before returning 202 to Odoo; a state-machine on those files survives across process boundaries
Protect the OpenClaw state directory, monitor and clean the failed queue according to your retention policy, and avoid sending secrets or regulated data through this channel unless your storage controls are adequate.
Telemetry backends may receive Odoo-related session or record identifiers, which can still be sensitive in some environments.
If telemetry is configured, operational identifiers and failure metadata are sent to an external OTLP backend. The artifacts describe this, and message bodies are not shown as telemetry fields.
set `config.diagnostics.otel.endpoint` to ship events to your OTLP backend automatically ... Span attributes ... `openclaw.sessionKey`, `openclaw.chatId`, `openclaw.reason`
Send telemetry only to trusted backends, restrict access to observability data, and disable optional OTEL log forwarding if these identifiers are sensitive.
A timeout or retry could cause duplicate chatter posts or repeated custom Odoo actions if the Odoo-side method does not de-duplicate requests.
The documented at-least-once retry behavior can duplicate delivery if the target Odoo method is not idempotent. This limitation is disclosed and bounded, but it matters for mutating workflows.
Hard-timeout late-deliver double-post ... XML-RPC delivery dedup still relies on Odoo-side `requestMessageId` idempotency; bounded by `DISPATCH_MAX_ATTEMPTS`.
Make custom Odoo reply methods idempotent using `requestMessageId`, and avoid non-idempotent record creation, payment, deletion, or notification methods as automatic reply targets.