Odoo REST API: What It Can (and Can't) Do

Not a native one, no. This is one of the most common points of confusion for anyone starting to evaluate an Odoo integration. Odoo's built-in external API is exposed over two RPC protocols, XML-RPC and JSON-RPC, both of which call the same underlying ORM methods. Neither of those is REST in the architectural sense: there's no set of resource URLs like /api/sale.order/42 that you GET, PUT, or DELETE against with plain HTTP verbs and status codes. If you've found documentation or a module claiming Odoo has REST endpoints, it's either describing JSON-RPC loosely as "REST-like," or it's a third-party or self-hosted addition, not something Odoo ships by default.

A single generic dispatch method, commonly reached as execute_kw, that takes a model name, a method name, and arguments, and runs it against Odoo's ORM as the authenticated user. Standard CRUD (search, search_read, create, write, unlink) is always available this way, and so is any other public method on that model, including business actions like confirming a sales order. See the guide on how Odoo's API actually works, linked below, for the full mechanics of authentication and calling it.

XML-RPC and JSON-RPC both predate Odoo's current form and map naturally onto exposing an ORM's methods directly: a single endpoint that can call anything the ORM supports, rather than hand-defining a REST resource and set of verbs for every one of the hundreds of models Odoo ships. It's a pragmatic choice for an ORM-centric framework, even though it means Odoo doesn't look like a typical modern REST or GraphQL API out of the box.

No. Every client language with an HTTP or XML-RPC library can call Odoo's existing RPC API: Python, JavaScript/Node, PHP, and plenty of others have mature libraries for exactly this. The practical effect of "no native REST" isn't that integration is blocked, it's that the calling code has to think in terms of model names and method calls (execute_kw("sale.order", "search_read", ...)) rather than REST-style URLs and verbs, a different shape of code, not a harder problem.

It's a genuinely common and reasonable pattern: build a small server that exposes a handful of proper REST (or GraphQL) endpoints your own frontend or a third-party system can call, and have that server translate each request into the equivalent Odoo RPC calls behind the scenes. This makes sense when the consuming client expects conventional REST (a mobile app framework, a no-code tool, a partner system you don't control), when you want to expose only a narrow, deliberately scoped slice of Odoo's data instead of the full ORM surface to that client, or when you want a layer that can cache, rate-limit, or reshape Odoo's data before it reaches the outside world.

If the thing calling Odoo is a web app or backend you're building yourself, there's usually no reason to invent a REST layer in between: calling Odoo's RPC API directly from that app's own backend is simpler and has one fewer moving part to maintain. The extra REST layer earns its cost specifically when something outside your control needs a conventional REST contract, not as a default architectural step for every Odoo integration.