Odoo API Examples: What a Call Looks Like, and What Takes the Time

Short, in every language. That is the part people expect to be hard, and it is not. Odoo exposes its models over HTTP, you name a model and a method, and you get JSON back. Below is the same read in each of the three transports Odoo supports, so you can see the shape before deciding which one your version needs.

# Odoo 19+ (JSON-2): a POST per method call
POST /json/2/sale.order/search_read
Authorization: bearer <api key>
{"domain": [["state", "=", "sale"]], "fields": ["name", "amount_total"], "limit": 5}

# Odoo 16 to 21 (JSON-RPC): everything through execute_kw
POST /jsonrpc
{"jsonrpc": "2.0", "method": "call", "params": {"service": "object", "method": "execute_kw",
 "args": [db, uid, key, "sale.order", "search_read",
          [[["state", "=", "sale"]]], {"fields": ["name", "amount_total"], "limit": 5}]}}

# Odoo 16 to 21 (XML-RPC), from Python's standard library
models = xmlrpc.client.ServerProxy(f"{url}/xmlrpc/2/object")
models.execute_kw(db, uid, key, "sale.order", "search_read",
                  [[["state", "=", "sale"]]], {"fields": ["name"], "limit": 5})

In JavaScript it is a fetch to the same endpoints; no client library is required on either side. The one rule that is not negotiable: these calls belong on a server you control, never in browser or mobile code, because the API key carries that user's full access rights.

New work on Odoo 19 should use JSON-2. On Odoo 16 to 18 it does not exist yet, so JSON-RPC is the practical choice. The model names, method names and search domains are identical across all three, so the transport is the only thing that changes; see the JSON-2 guide for the migration detail.

Everything around them. A demo script that reads five orders is an afternoon. An app that a warehouse uses every day, against a real database, is a different piece of work, and the gap between the two is where integration projects actually run aground:

• Getting the right records back. Multi-company databases return more than you expect, archived and draft records sneak into results, and the correct domain for "the orders this user should see" is rarely the obvious one.
• Writing without breaking Odoo's own logic. Setting a field directly and calling the method behind the button are not the same thing: one skips every side effect Odoo would normally run. Knowing which method to call, and what it does downstream, is the job.
• Failures that do not look like failures. One transport reports errors with a 200 status. Writes can partly apply. Two people can act on the same record at once. Code that assumes the happy path looks fine in testing and quietly corrupts data in production.
• Access rights. The API acts as a user, so the integration user's groups decide what works. Testing as an administrator hides exactly the errors your users will hit.
• Speed. The naive version makes one call per row and crawls. Making it fast is about asking Odoo for aggregates and batches instead of looping.
• Staying working. Field renames, new required fields, expiring API keys, and the removal of the RPC endpoints in Odoo 22 all land on the integration, not on Odoo.

None of that is exotic, and none of it shows up in a getting-started example. It is simply the difference between code that calls Odoo and an app people can rely on.

If the goal is to pull a few records into a spreadsheet once, a script is right and the snippets above are a fine start. If people are going to use it daily, on a phone, in a warehouse, with real money attached to the records it writes, the API call is the small part: the screens, the validation, the error handling and the maintenance are the project. That is what we build, as the apps on our work page show, usually in a couple of weeks and for a fixed price.

Tell us the workflow you want simplified and we will tell you honestly which of the two it is, and what it would take.