Odoo API Integration in 2026: JSON-2, Webhooks, Dashboards

If you run a business on Odoo, the External API is the part of the platform most teams never touch and the part that tends to pay for itself first. Everything you see in the Odoo web client, every sales order, invoice, contact, and stock move, is reachable from outside through the Odoo API. That is what lets you push e-commerce orders in, pull financial data out, and build the one dashboard your CEO keeps asking for.

The architectural decisions for building on top of an ERP are largely the same from one system to the next. The patterns I described in my Silverfin API integration guide for an accounting platform apply to Odoo, with one caveat: the rules changed in late 2025. Odoo 19 deprecated the integration approach that almost every existing connector, tutorial, and automation depends on. If you are scoping an Odoo API integration this year, the playbook on the first page of Google is mostly out of date.

What Is the Odoo API?

The Odoo API is the External API that gives outside applications programmatic read and write access to every record in an Odoo ERP database. As of Odoo 19 (released September 2025) it is exposed as the modern JSON-2 API, with the legacy XML-RPC and JSON-RPC endpoints deprecated but available through 2027 for Odoo Online and 2028 for self-hosted deployments. Access is gated to the Custom plan or any self-hosted deployment.

Odoo is built on a simple philosophy: everything is a model. A customer is a record in the res.partner model, a sales order lives in sale.order, an invoice in account.move, a product in product.product. The API lets external systems read and write those models directly, which is what you need for reporting, syncing, and automation.

The business takeaway: you are not limited to the reports Odoo ships with. If the data exists in Odoo, you can get it out and combine it with data from Shopify, Stripe, HubSpot, or a warehouse system to build something Odoo could never show you on its own.

Two facts determine almost everything about how an Odoo API integration will work: which version of Odoo you run, and which plan you are on. Those are the things teams forget to check first.

What Changed in Odoo 17, 18, and 19

Odoo 17 (October 2023) introduced native webhooks. Odoo 18 (October 2024) was mostly additive: performance, UX polish, better multi-company. Odoo 19 (September 2025) replaced the legacy XML-RPC and JSON-RPC endpoints with a new JSON-2 API, made API keys mandatory with a three-month maximum lifetime, and auto-generates per-database API documentation. The differences matter for any Odoo integration you are planning today.

Odoo 18 was a calmer release: faster navigation, smarter inventory rules, native loyalty programs, nothing that broke existing connectors. Odoo 19, announced at Odoo Experience in Brussels on September 18, 2025, is the release that should be on your radar. Three changes matter before you scope any new work.

The headline change is the new API. The legacy XML-RPC and JSON-RPC endpoints, the ones that power virtually every existing connector and every “Odoo API integration” tutorial written before late 2025, are now formally deprecated. Odoo’s own documentation confirms they are scheduled for removal, replaced by a cleaner JSON-2 API. The migration window runs out to 2027 for Odoo Online and 2028 for self-hosted, so nothing breaks tomorrow, but every new integration you build on the old endpoints is a future migration you are signing up for.

API keys are now mandatory. Odoo 19 stops accepting passwords for API access and requires API keys instead, with a maximum lifetime of three months. That is a security win, but it means any long-running integration needs a key rotation plan baked in from day one.

The third change is a developer-experience upgrade: every Odoo 19 database now auto-generates a live API documentation page listing every model and method on your specific instance, including any custom fields your team added. That removes a lot of guesswork from scoping an integration.

Odoo 19 also leaned hard into AI, adding database-querying AI agents, natural-language “Ask AI” search, AI-assisted invoice scanning, and AI-generated dashboards. If compliance matters to you, some of those AI features route data to third-party model providers, so an air-gapped or regulated deployment should review what leaves the instance before switching them on.

If you are weighing an Odoo 18 to 19 migration, the headline for your integration team is simple: 17 broke views, 18 was gentle, 19 broke the API. Budget accordingly.

Which Odoo Plans Have API Access?

The Odoo External API is only available on the Custom plan or a self-hosted deployment. The One App Free and Standard plans on Odoo Online do not expose it at all. This is the most common surprise in early-stage Odoo integration projects, and it has killed more than one project before a line of code was written.

In one sentence: if you want serious Odoo API integration, you need the Custom plan or a self-hosted deployment. The Custom plan vs Standard plan question is a prerequisite, not a detail to handle later. If a business tells me they are on Standard and they want a custom dashboard, the first conversation is about a plan upgrade, not about architecture. Sort this out on day one.

The same Custom-plan gate applies to Odoo Studio, custom modules, and multi-company support, so a business with any real integration ambition is almost always on Custom anyway. Check anyway.

The Gotchas Nobody Mentions

Every ERP has personality, and Odoo’s shows up in a handful of places that reliably trip up first-time integrators. None of these are dealbreakers. All of them are cheaper to know about before you start than after.

A “partner” is everyone. In Odoo, the res.partner model holds customers, vendors, employees, and contacts all at once. A single contact can be both a customer and a vendor simultaneously. Companies and the people who work at them are linked through a parent and child relationship. Get this wrong during a data import and you create thousands of duplicate or orphaned records, which is the most common way an Odoo CRM integration goes sideways in week one.

Relational fields have their own grammar. When you link records over the API, such as adding a product line to an order, Odoo does not accept a plain list of IDs. It expects the ORM command tuple syntax documented under Relational Fields. For example, linking an existing set of records uses a small instruction tuple:

# Replace a record's tags with a specific set
'tag_ids': [(6, 0, [12, 15, 23])]

That (6, 0, [...]) is not a typo, it is Odoo’s way of saying “replace the whole set.” There are similar commands to add a new record (0), update fields on a linked record (1), unlink (3), or clear the whole set (5). Your integration partner needs to know this exists, because the error messages when you get it wrong are unhelpful in the extreme.

External IDs matter more than database IDs. Records created through the Odoo interface do not automatically get a stable external identifier. If you plan to update Odoo records from an outside system, assign external IDs at creation time. Skip this and you are one re-sync away from duplicating data or overwriting the wrong record.

Timezones will catch you. Odoo stores every timestamp in UTC but displays it in each user’s local timezone. Ask the API for “today’s invoices” using the wrong boundary and your finance team in Dubai will see transactions from the wrong day. Always be explicit about timezone in any reporting integration.

Multi-company and multi-currency are effectively different products. If a business runs several legal entities in one Odoo database, every query needs an explicit company filter or you will mix data across entities. Multi-currency adds automatic exchange-rate journal entries that your integration must respect rather than fight. These are solvable, but they are not free.

Rate limits are real on Odoo Online. Self-hosted and Odoo.sh deployments are limited only by your own infrastructure. But Odoo Online (the SaaS version) throttles the external API to roughly one call per second with no parallel calls, per their acceptable use policy. That single constraint shapes everything: it pushes you toward batching large reads, syncing big extractions overnight, and using webhooks instead of constant polling.

Community vs Enterprise changes the surface. Both editions expose the same External API, but Odoo Community and Enterprise differ in what data exists to integrate against. Community has invoicing but not full double-entry accounting, and it lacks Studio, so there are fewer custom fields to handle but also fewer features to build on. Confirm which edition you are dealing with before you promise anyone “Odoo handles the accounting.”

Does Odoo Support Webhooks?

Yes. Odoo has supported native webhooks since Odoo 17 (October 2023), for both incoming and outgoing events, configured without code from Settings, Technical, Automation Rules. Odoo 19 added webhook management and delivery logs inside Studio, with a resend button for failed deliveries. They should be the default for any modern Odoo integration.

For most of Odoo’s history, there was no native way for the platform to tell an outside system “something just happened.” You had to poll: ask Odoo every few minutes whether anything changed, which is wasteful, slow, and bumps straight into that one-call-per-second ceiling on Odoo Online. The two directions now available:

• Incoming webhooks trigger an automation when an outside system calls in
• Outgoing webhooks fire a notification to your application the moment a record changes

If you are building anything that needs to react when an order is confirmed, an invoice is paid, or a lead comes in, use webhooks rather than a polling job. They are faster, cheaper, and more reliable. One thing to flag with your integration partner: webhooks need extra configuration in multi-database deployments.

Caution: many third-party automation tools were slow to adopt Odoo 19’s new endpoints. As of late 2025, some popular no-code connectors were still calling the deprecated APIs and triggering Odoo’s removal warnings. If you are relying on an off-the-shelf connector like Zapier or Make, confirm it supports the JSON-2 API before you build a process around it.

Business Use Cases: Pulling Data Out, Pushing Data In

Most Odoo ERP integration projects fall into one of two directions. These are the ones I see pay off.

Pulling data out of Odoo is the more common direction, usually in service of reporting and visibility:

Pushing data in to Odoo is about automation and keeping systems in sync:

How to Build an Executive Dashboard on Top of Odoo

To build an Odoo executive dashboard, pull data through the JSON-2 API or replicate it into a data warehouse, model it cleanly outside Odoo, and connect a BI tool such as Power BI, Tableau, Metabase, Looker, or Superset to the warehouse rather than to live Odoo. Six KPIs at one level of drill-down is enough for an executive view. The blueprint below is tool-agnostic and small enough to ship in weeks.

The most requested Odoo dashboard project I see is some version of this brief:

Our CEO wants one screen showing pipeline, revenue, cash, and inventory, pulling from Odoo plus our other systems.

It works well as a proof of concept: small enough to ship in weeks, and the value lands the moment leadership opens it.

1. Pick six KPIs, not sixty. A good executive view answers one question: is the business on track this week? A typical set:
   • Net new revenue
   • Gross margin
   • Days sales outstanding (DSO)
   • Pipeline coverage
   • Inventory days of supply
   • Customer satisfaction

   Each gets a current value, a trend line, and one level of drill-down. Resist the urge to add more.

2. Map each KPI to its source. Revenue and margin come from account.move and sale.order in Odoo. Receivables come from Odoo’s aged reports. Pipeline comes from crm.lead. Inventory comes from the stock models. Customer satisfaction usually lives outside Odoo entirely, in a survey tool, which is the reason you build this layer outside Odoo in the first place.

3. Choose how you extract. For modest volumes, call the Odoo JSON-2 API on a schedule, say every fifteen minutes during business hours. For larger volumes, replicate Odoo data continuously into a small data warehouse (think BigQuery, Snowflake, or Postgres), syncing only what changed since the last run.

4. Model the data in a warehouse, not in the dashboard. This is the step teams skip and later regret. Land your Odoo data in a clean, simple data model in a warehouse, then point the dashboard at the warehouse. This shields your dashboard from Odoo’s annual model changes and keeps your live ERP fast for the people actually running the business. For time-series snapshots of ERP data, see my TimescaleDB implementation guide.

5. Pick the visualization layer last. Power BI, Tableau, Metabase, Looker, Superset, all of them work. The right choice is whatever your company already has licenses and skills for. An Odoo Power BI integration and an Odoo Tableau integration are the same project with a different final step. One rule: in production, the dashboard tool connects to your warehouse, never directly to live Odoo.

6. Add governance up front. Decide who sees what, how often it refreshes, and who can change it before you launch, rather than after someone sees a number they should not have.

Why Build Business Intelligence Outside Odoo

Odoo’s native dashboards are good, and Odoo 19 made them better with AI-assisted creation and natural-language queries. For a single department watching its own numbers, native Odoo business intelligence is often enough. Businesses outgrow it at a few predictable boundaries, and recognizing them early saves a painful re-platforming later.

The shape of the answer is the same in almost every project: keep Odoo fast for transactions, replicate its data into a warehouse, and build reporting on top of that. Your ERP stays responsive, your executives get one unified view, and your dashboards survive the next Odoo upgrade.

Case Study: A B2B Distributor on Odoo Enterprise

To make this concrete, picture a mid-sized B2B distributor running on Odoo Enterprise with around 120 employees. They sell through three channels:

• A direct sales team on Odoo CRM
• A B2B e-commerce site
• A presence on an industrial-supply marketplace

They operate two legal entities, hold inventory in three warehouses, and outsource fulfillment. This is an illustrative composite, not a real company, but the shape is one I see often.

The problem: the finance lead spent the first three days of every month assembling a board pack from spreadsheet exports. The numbers never quite reconciled, because the e-commerce platform and Odoo disagreed about whether shipping counted as revenue. Sales managers needed two logins to see marketplace performance. The CEO wanted weekly visibility and was getting monthly, at best.

The approach is a three-phase project:

1. Clean the data - deduplicate customers that existed in both Odoo and the e-commerce platform, standardize product codes across channels, and assign external IDs so future syncs stay idempotent.
2. Build the integration layer - use Odoo’s native webhooks to push every confirmed sale to a small middleware service that enriches it with channel and fee data, then writes a unified record to a managed data warehouse, with nightly API syncs handling master data.
3. Deploy a single executive dashboard - refreshed every fifteen minutes during business hours, with a stripped-down view for sales managers.

Plausible outcomes. Published vendor case studies for projects of this shape report results in the range of:

• A roughly 75 percent reduction in reporting effort
• A sharp drop in manual data-entry errors
• Broad adoption across departments once a single unified dashboard replaces manual spreadsheets

Those are vendor-reported, upper-end figures, and real results depend heavily on how clean your data is at the starting line. The direction is consistent, though: once you stop hand-assembling reports and let an integration do it, the time savings are large and immediate.

When NOT to Build a Custom Odoo Integration

Custom integration is not always the right answer. Skip it when the use case fits any of these:

• You are on the Standard or One App Free plan and not ready to upgrade. The External API simply is not available. Either commit to the Custom plan or accept Odoo’s native reports as your ceiling.
• A single department needs a single report. Odoo’s built-in studio and dashboards are good enough for one-team use cases. Custom integration overhead only pays off when multiple systems or audiences are involved.
• You expect Odoo to be replaced within 12 months. Building a dashboard against a system you are about to migrate off is throwaway work. Wait for the platform decision.
• Nobody owns the data quality. No integration fixes upstream bad data. If customers are duplicated and product codes are inconsistent in Odoo today, those problems flow straight into the warehouse.

What to Do Now

If you are scoping an Odoo integration in 2026, the honest short list:

• Confirm the version and plan before anything else; both can stop a project cold
• Build new integrations against the JSON-2 API if you are on Odoo 19, rather than writing code you will have to migrate
• Use webhooks rather than polling wherever you can
• Treat external IDs as essential, not optional
• Budget for the annual upgrade. Odoo will change something every October, and a small amount of planning turns that from a fire drill into a routine

If you are building business intelligence on top of Odoo, do not point your dashboard at the live database. Replicate to a warehouse, model the data cleanly, start with six KPIs, and let the visualization tool be the last decision you make rather than the first.

The interesting work in any Odoo API integration starts after the plumbing is in place. It lives in the product decisions you make once the data is in your hands: which numbers your leadership team trusts, how fresh they need to be, and what the dashboard tells someone the moment they open it. Get the foundations right and those become the only questions left.

Need help building an integration on top of Odoo or another ERP? I help teams with API architecture, data sync design, and dashboard projects for business-critical data. If you are scoping an Odoo 19 migration or a dashboard project, reach out at [email protected].

Further Reading

• How to Integrate Silverfin API: Ruby, Python, TypeScript - the same architectural patterns applied to an accounting platform
• TimescaleDB in Rails: A Practical Implementation Guide - time-series storage for snapshot data pulled from an ERP
• PostgreSQL Optimization in Rails: Cut Query Times by 95% - indexing strategies for warehouse and snapshot tables
• Solid Queue in Rails 8: Install, Migrate, and Deploy - scheduling the sync jobs behind an integration
• Odoo External API Reference (v19) - the canonical Odoo docs for the JSON-2 API
• Odoo ORM Reference - the relational-field command tuple grammar and model conventions
• Odoo Automation Rules and Webhooks - configure outgoing webhooks without code
• Odoo Acceptable Use Policy - the source of the one-call-per-second Odoo Online rate limit
• Odoo Pricing and Plans - confirm which plan exposes the External API
• Power BI Connect to Data - reference for the BI side of an Odoo Power BI integration