Actions and Methods

What you can call depends on the API version. v1 has a fixed allowlist of nine actions with positional arguments; v2 calls any public model method with named arguments. Both reach the same Odoo methods — only the shape differs, so don't mix the two.

v1: the 9 allowed actions

The action field must be one of these 9 values. Anything else is rejected with HTTP 400 and JSON-RPC code -32001.

The action is passed straight through as the Odoo method name in execute_kw, except for call_method, where fn_name is used instead.

The model and fields are arbitrary — they are named in the request body and forwarded as-is. The proxy never hardcodes or mirrors your Odoo schema, so a model or field you add in Odoo is reachable immediately, with no proxy redeploy, config change, or schema regeneration. That holds on v2 too.

params and keyword per action

params is the positional-argument list of execute_kw, so for the search-style actions the domain is its first element — hence the doubled brackets. keyword carries kwargs such as fields, limit, offset, order, and context.

{ "action": "search_read", "model_id": "res.partner",
  "params": [[["is_company", "=", true]]],
  "keyword": { "fields": ["name", "email"], "limit": 50, "order": "name asc" } }

{ "action": "write", "model_id": "res.partner",
  "params": [[42], { "name": "Acme LLC" }] }

{ "action": "call_method", "model_id": "sale.order", "fn_name": "action_confirm",
  "params": [[42]] }

v2: methods and their kwargs

On v2 (POST /v2/odoo/execute, Odoo 19+), method names the Odoo method directly and kwargs carries every argument by name. There is no allowlist, no fn_name, and no positional params. Odoo checks each key against the method's Python signature, so the keys below must be spelled exactly as shown.

Any call can also carry context (lang, tz, allowed_company_ids, …).

{ "model_id": "res.partner", "method": "search_read",
  "kwargs": { "domain": [["is_company", "=", true]], "fields": ["name", "email"], "limit": 50 } }

{ "model_id": "res.partner", "method": "create",
  "kwargs": { "vals_list": [{ "name": "Acme Inc" }] } }

{ "model_id": "sale.order", "method": "action_confirm",
  "kwargs": { "ids": [42] } }

{ "model_id": "res.partner", "method": "name_search",
  "kwargs": { "name": "Acm", "limit": 5 } }

The rules that matter:

• Keys are Odoo's Python names, verbatim. vals_list, not valsList; allfields, not allFields. Field names inside vals, domain, and context are sent exactly as Odoo writes them too.
• The domain is the list itself — "domain": [["is_company", "=", true]]. An empty domain is [].
• Leave out what you don't set. Odoo's own defaults then apply; null means Python None, which is not the same thing.
• ids only for record methods. Sending ids to an @api.model method (search, search_read, search_count, fields_get, create, name_search, …) fails with error code 422, as does an unknown or misspelled key.
• model_id and method may contain only A-Z a-z 0-9 _ . and can't start with .; anything else is rejected with HTTP 400 / -32007 before Odoo is contacted. Odoo refuses private (_-prefixed) methods with code 403.

Relational fields (both versions)

For one2many and many2many fields, Odoo uses command tuples inside the values dict — [[6, 0, [ids]]] to replace, [[4, id]] to link, [[0, 0, {vals}]] to create and link. They pass through create and write unchanged on both versions. Check the field's type with fields_get first.