Problem
A syntactically valid JSON-2 request can still carry excessive access, invoke the wrong public method, or leave partial state across multiple transactions. Integration security is more than keeping an API key out of source control.
Evidence baseline
Odoo 19 accepts API keys as bearer tokens and documents a rotation sequence: create the replacement, deploy and verify it, then revoke the previous key. [K1]
JSON-2 applies the calling user’s ACLs, record rules, and field access. The service identity is therefore part of the security boundary, not merely a technical login. [K2]
Public model methods can be called over RPC with client-selected parameters. Odoo’s security documentation says the record and parameters must be treated as untrusted. Methods beginning with _ are not exposed through the external API. [K3]
Each JSON-2 call is a separate transaction. A client-side sequence has no all-or-nothing guarantee. [K4]
Pre-production checklist
- Dedicated service user: do not use a personal account or administrator; grant only the groups required by the flow.
- Key handling: keep keys in a secret manager, never in source, logs, analytics, or prompt content.
- Verified rotation: create a new key, deploy it, run a smoke test, and only then revoke the old key.
- Test effective access: run reads and writes with the actual service identity on representative data to exercise ACLs, record rules, and field access.
- Client allowlist: constrain the models, methods, and fields the integration may use; reject targets outside the list.
- Review public methods: prefer standard ORM methods. For custom methods, validate state, ownership, and parameters on the server rather than trusting client checks.
- Preserve atomicity: when several steps must succeed together, put them in one tested server-side method instead of several JSON-2 requests.
- Ability to stop: assign an owner and provide key revocation, a kill switch, and an audit trail before enabling writes.
Incident response
Revoke a suspected key, stop the worker or client, retain request IDs and audit logs, then inspect the records reachable by the service user’s permissions. Issue a replacement only after addressing the root cause and any excessive access.
Limit
This checklist does not replace a custom-module security review, prove that record rules are correct, or replace business-flow tests. Dynamic documentation and the live registry remain the authority for the target database’s model, method, and field surface. Least privilege, allowlists, and secret managers are operational recommendations layered on Odoo’s documented controls.