Duration: 26:34
PART 1 — Analytical Summary 🚀
Context 💬
In this 26-minute engineering talk, Julian, a software developer at Odoo, explains how external systems should integrate with Odoo going forward. The big news: the long-standing XML-RPC and its sibling JSON-RPC are deprecated in Odoo 19, replaced by a simpler, modern endpoint called JSON-2. The session walks through why legacy RPC is being retired, what Odoo tried (and abandoned) with REST specifications, and how JSON-2 streamlines integration while improving security and error handling. There’s also a surprise: per-database, auto-generated API docs you can run against your live instance.
Core ideas & innovations 🧠
For years, Odoo exposed three RPC “services” — db, common, and object — with developers funneling model operations like search, read, create, and write through the generic execute/execute_kw gateways. This design dates back to TinyERP-era constraints (no ORM, no web client), and it never fully caught up. Some database management functions behaved inconsistently (e.g., “create database” yielded an empty DB without base installed). Worse, XML-RPC can’t serialize 64-bit integers, which blocks access to large record IDs in high-volume environments.
Odoo explored cleaner alternatives: a better RPC encoding with big-int support, then REST via OpenAPI and JSON:API. Retrieval semantics mapped reasonably well, but writes and business actions (e.g., confirming a sale order) didn’t fit the constraints of those specs. After multiple attempts, the team concluded that “pure REST” specs couldn’t express Odoo’s model/method patterns without contortions.
Enter JSON-2 in Odoo 19. It’s a straightforward HTTP interface: POST /json/2/<model>/<method> with a JSON body for parameters, an Authorization header for API keys, and a custom header to select the database. It returns proper HTTP status codes (no more “HTTP 200 even on error”) and standard JSON error payloads. JSON-2 focuses on the former “object” service — model methods — and intentionally leaves out the legacy “db” and “common” service calls, which are covered by established public endpoints (e.g., a new /web/version replaces the old “version” call).
There are a few deliberate constraints. JSON-2 requires named parameters, so integrators must use the exact argument names defined by Odoo methods (e.g., vals_list for write). To resolve the 2FA friction in machine-to-machine scenarios, Odoo mandates API keys for JSON-2, with a default maximum lifetime of 90 days for regular users (admins can create permanent keys). The internal web client keeps using JSON-RPC under renamed controller types to avoid confusion (type “json” becomes “jsonrpc”; the new family is “json2”).
The session closes with a practical gift: every database now ships with live, auto-generated docs at /doc. You can browse fields, see public methods, filter by installed modules (including custom ones), and copy sample code (Python, JavaScript; more welcome via PRs). Provide an API key, and you can execute calls right from the documentation UI — a powerful onramp, with the caveat that it hits your live DB. A “dry run” mode is being considered for a future release.
Impact & takeaways 💼
The new JSON-2 API cuts through historical complexity and aligns Odoo integrations with modern developer expectations. It simplifies calling model methods, fixes big-integer serialization limits, and restores predictable HTTP semantics with proper status codes. API key enforcement brings clearer operational security, consistent with industry norms and key rotation guidance.
For teams planning migrations, the deprecation timeline is tight but clear: the /xmlrpc, /xmlrpc/2, and /jsonrpc endpoints are deprecated in Odoo 19, with removal on Odoo Online (SaaS) in 19.1, and on Odoo.sh/on-prem in Odoo 20. If you must keep legacy RPC on self-managed instances temporarily, you could archive and re-install the RPC module — but don’t count on it for SaaS or beyond Odoo 20.
Practically, JSON-2 means:
- Simpler, language-agnostic integrations using any HTTP+JSON client ⚙️
- Named-argument calls to model methods via /json/2/<model>/<method>
- Proper error signaling with 4xx/5xx responses
- Support for big integers and batch operations (create/write lists in one transaction)
- Per-database /doc pages to explore models and run example code, with access controlled by standard Odoo groups
The net effect: a leaner, more secure, and more maintainable surface for building on top of Odoo — without forcing a REST mold that doesn’t fit Odoo’s domain-driven method semantics.
PART 2 — Viewpoint: Odoo Perspective
Disclaimer: AI-generated creative perspective inspired by Odoo's vision.
Simplicity has always been our north star. JSON-2 is the pragmatic path to give developers a clean, predictable way to call business logic without shoehorning Odoo into an API shape that breaks core concepts. We chose clarity over fashion: precise methods, named parameters, real HTTP errors, and API keys that reflect how integrations operate today.
I’m particularly excited about the per-database documentation. When your custom modules appear alongside standard models and runnable examples, the learning curve drops for everyone — partners, customers, and new team members. It’s another step toward an integrated platform where building is fast, safe, and enjoyable for the whole community.
PART 3 — Viewpoint: Competitors (SAP / Microsoft / Others)
Disclaimer: AI-generated fictional commentary. Not an official corporate statement.
Odoo’s move away from legacy RPC is sensible and overdue. JSON-2 acknowledges that method-oriented business systems don’t always map cleanly to REST specifications. The shift to API keys, error standardization, and big-int support will help developer adoption and reliability. The live, per-instance documentation is a strong UX touch that lowers onboarding friction.
For large enterprises, questions will remain around long-term governance: API lifecycle management, compliance tooling, and observability at scale. JSON-2’s method-centric design differs from resource-first REST or strongly-typed Graph approaches; that can be powerful, but it may demand additional discipline in versioning and change control. The deprecation schedule is aggressive — customers with complex landscapes will need careful migration planning.
PART 4 — Blog Footer Disclaimer
Disclaimer: This article contains AI-generated summaries and fictionalized commentaries for illustrative purposes. Viewpoints labeled as "Odoo Perspective" or "Competitors" are simulated and do not represent any real statements or positions. All product names and trademarks belong to their respective owners.