CRUD operations¶

Start with search_read for bounded reads. Use explicit field lists and domains so responses remain predictable.

Search and read¶

POST /json/2/res.partner/search_read

{
  "domain": [["customer_rank", ">", 0]],
  "fields": ["name", "email", "company_id", "write_date"],
  "limit": 100,
  "order": "id asc"
}

Use separate search and read calls only when the IDs have value by themselves or you need staged processing. Records can change between calls.

Create¶

Inspect required and readonly fields before creating. Odoo's ORM create method accepts vals_list in JSON-2:

POST /json/2/res.partner/create

{
  "vals_list": [
    {
      "name": "Example Customer",
      "company_type": "company",
      "email": "finance@example.com"
    }
  ]
}

The Postman mutation folder is intentionally separated from read operations. Run it only against an approved environment.

Update¶

POST /json/2/res.partner/write

{
  "ids": [42],
  "vals": {
    "email": "accounts@example.com"
  }
}

Every record in ids receives the same values. For concurrency-sensitive updates, read write_date, apply an idempotency strategy, and re-check state in a server-side atomic method.

Delete¶

POST /json/2/res.partner/unlink

{
  "ids": [42]
}

Deletion may be blocked by access rights, relation constraints, accounting immutability, or business state. Prefer archival through an active field when the model supports it.

Defaults¶

Use default_get before constructing records whose defaults depend on company, context, or configuration:

POST /json/2/sale.order/default_get

{
  "fields_list": ["company_id", "currency_id", "warehouse_id"]
}

Defaults do not replace onchange logic. Complex UI-created records may need a dedicated integration method rather than direct CRUD.