Odoo API development: the connection layer itself

Odoo exposes its ORM to external clients over JSON-2 (an HTTP JSON API, new in Odoo 19) and, on every version from 16 up, over XML-RPC and JSON-RPC. All three let an authenticated external client call the same core methods Odoo's own web client calls internally: search_read and read_group to query records, create and write to add or update them, and unlink to delete them, plus the ability to call specific business methods on a model, like confirming a sales order or validating a stock transfer, instead of trying to fake that behavior by writing raw field values.

Authentication is an API key generated for a dedicated integration user (a bearer header with JSON-2; a login step that returns a user id with the RPC protocols). Every call is then subject to that user's normal Odoo access rights and record rules; the API doesn't bypass Odoo's permission model, it operates inside it.

A read-only integration pulls data out of Odoo to display or export elsewhere (a dashboard, a report, a sync to another system's copy of the catalog). It's inherently lower-risk: there's no way to corrupt Odoo data through a query. A write-back integration creates or updates real records (a new sales order, a confirmed purchase order, an updated stock count) and needs real care: input validation before the write, clear handling of what happens if a call partially fails, and calling the correct workflow method rather than writing raw state fields and hoping Odoo's own business logic doesn't get bypassed in the process. The guide on read-only vs. write-back integrations linked below goes into this in more depth.

The recurring patterns: syncing e-commerce or marketplace orders into sale.order; pushing web form or chat leads into crm.lead; connecting a mobile or field app to stock or purchase workflows; syncing product and stock data with a separate warehouse or point-of-sale system; and using Odoo's own Automated Actions to trigger outbound calls to another service when something changes inside Odoo. Most integration requests are a variation on one of these.

Not a generic connector or a one-size-fits-all SDK: the specific integration for the specific workflow, including error handling and clear behavior when something goes wrong (a call fails, a required field is missing, Odoo rejects the write), and a plain description of exactly which Odoo models and fields the integration touches. Pricing depends entirely on which models and workflows are involved; see the general pricing guide below or the pricing section on the homepage for a starting sense of range.