Duration: 25:19
PART 1 — Analytical Summary 💼
Context: Who’s speaking and why it matters
In this 25-minute session, Nicolas Sahl, a developer at Odoo, walks through how external applications can interact with Odoo via its external API, with a focus on what’s new in Odoo 19. The talk blends a practical tour of the new API documentation experience, hands-on examples (largely in Python), and a Q&A that clarifies security, pagination, performance, and migration concerns. For teams building integrations, automations, or custom connectors, these changes materially simplify discovery, coding, and maintenance. 🚀
What’s new in Odoo 19: Self-documented, API-key driven, and easier to code ⚙️
The headline feature is a new, built-in documentation interface at the instance route /doc. From any Odoo 19 instance, authenticated technical users can navigate all models, their fields, and public methods, and see method-level documentation. Even better, the page can generate ready-to-run code snippets in four languages (e.g., Python and JSON). Choose a model, pick a method, view its arguments, select a language, and you get a working example tailored to your instance. You can even test calls right on the page by choosing JSON; the page will prompt for your API key and execute the call.
Access now relies on API keys rather than username/password (which would otherwise require 2FA on each run). Users generate API keys from their profile, specifying a purpose and validity period. Keys are shown only once and should be stored securely (ideally outside your codebase). The doc page itself is restricted to members of the “Technical Documentation Users” group.
Under the hood, Odoo 19 introduces a new JSON endpoint often referred to as “JSON 2” (route: /json2). Compared to older XML-RPC and JSON-RPC, JSON 2 emphasizes clearer request/response semantics and returns meaningful HTTP status codes (e.g., 404, 500), instead of always 200. The new API favors named parameters; positional parameters are still accepted, but they trigger a server-side lookup to resolve names, adding latency. Consuming the API is straightforward: it’s plain HTTP with headers for authentication, a consistent base URL, and the model/method defining each call.
Core ideas & innovations: Better discoverability, safer automation, smoother migration 🧠
The improved developer experience comes from three pillars. First, the self-documenting /doc hub centralizes model, field, and method intelligence, with code samples that reflect your exact environment—reducing guesswork and onboarding time. Second, API keys make automation safer and more manageable: they’re scoped to a user’s permissions, can be time-bound, and avoid 2FA hurdles for scripts. Third, compatibility considerations are addressed by the maintained “Odoo client lib,” which works across legacy XML-RPC, JSON-RPC, and the new JSON 2—helpful if you support multiple Odoo versions.
Transactions and performance are treated with refreshing clarity. Each API call runs in its own PostgreSQL transaction. If your script creates an order and then lines via multiple calls, you risk partial writes if something fails mid-loop. In Odoo’s server-side code, a single method would wrap these operations atomically. For performance and rate-limiting, the guidance is to avoid “search in loops” and instead use aggregation patterns like read_group, cutting dozens of calls down to one. This matters because cloud providers enforce rate limits—scripts that fire off hundreds of calls rapidly are likely to be throttled.
Impact & takeaways: Faster build times, clearer errors, and predictable access control 💬
Developers get a faster path from idea to integration: browse models, inspect method signatures, generate code, try live calls, and ship. The API returns proper HTTP status codes for errors, making it easier to handle failures programmatically. Security is consistent and predictable: API calls obey the exact same access rights and record rules as the web client; private methods (underscore-prefixed) remain off-limits. Pagination, via standard limit/offset, is supported.
From a migration standpoint, the new path is clear: XML-RPC (since 6.1) and JSON-RPC (since v8) are both slated to be removed in Odoo 20, while JSON 2 is available starting in Odoo 19. The “Odoo client lib” eases transitions, but scripts still need updating when underlying models or methods change across Odoo versions (e.g., models renamed or removed). The API works on Odoo SaaS and Odoo Community, supports “service users” with per-use-case tokens, and can be disabled or restricted via web-server rules (blocking /json2) or by removing users from the documentation group.
Key practical notes from Q&A: - Permissions are user-based, not endpoint-based. You can’t fine-tune per-endpoint access; Odoo’s record rules and ACLs apply. - Public access isn’t supported; use web controllers for public-facing endpoints. - Rate limiting depends on your hosting provider; large bursts (e.g., 1,000 calls) will likely be throttled. - Odoo AI methods are not exposed for public API use. - Multi-database setups are supported (via db parameter or URL-to-db mapping). - Related/nested exports are possible through the existing export feature, which can traverse many2one/many2many relationships.
In short, Odoo 19 makes the external API more discoverable, safer for automation, and cleaner to program against—while reinforcing best practices around transactions, rate limits, and security. 🚀
PART 2 — Viewpoint: Odoo Perspective
Disclaimer: AI-generated creative perspective inspired by Odoo’s vision.
We’ve always believed that great software should be simple to use and easy to integrate. The new API and /doc page are about removing friction—letting developers explore models, understand methods, and ship integrations without learning a new dialect every time. When you can see and try everything in one place, you move faster and make fewer mistakes.
We kept the focus on consistency and community: same permissions, same business logic, better tooling. By favoring named parameters and proper HTTP status codes, we help teams build reliable automations. It’s not just an API; it’s a transparent window into Odoo’s models and methods—so partners, customers, and contributors can build together with confidence.
PART 3 — Viewpoint: Competitors (SAP / Microsoft / Others)
Disclaimer: AI-generated fictional commentary. Not an official corporate statement.
Odoo’s move to a self-documented API is smart. It shortens the developer learning curve and aligns well with SMB and mid-market needs. The emphasis on consistent permissions and named parameters should improve integration reliability. We also appreciate the clear migration path away from legacy RPCs.
That said, large enterprises will watch for API governance at scale—formal OpenAPI specs, advanced throttling and SLAs, audit trails, and compliance tooling across multi-region deployments. The transaction model (one transaction per call) can surprise teams expecting atomic multi-step operations. UX differentiation is strong; enterprise depth in areas like API lifecycle management and compliance will be the real test as deployments grow.
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.