Odoo Integration Options: API, Connectors, Middleware

There are three ways to connect Odoo to another system: call Odoo's external API directly (the JSON-2 API, plus webhooks built as automation rules), install a prebuilt connector that someone else maintains, or route the data through middleware that sits between Odoo and your other software. The right choice depends less on the other system than on four facts about your Odoo: where it is hosted, which pricing plan it is on, which writes must succeed or fail together, and who will own the integration after go-live. Good Odoo integration services settle those four facts first and then pick a route per data flow, which usually means a mix.

This guide is for whoever chooses the approach. Odoo's behaviour below comes from the Odoo 20.0 external API documentation and the other Odoo pages linked in each section, all checked on 21 October 2026.

The three routes at a glance

	Direct API	Prebuilt connector	Middleware
What it is	Your code calls the JSON-2 API, or a system calls an Odoo webhook	A module or service built for one pairing, such as Odoo and Amazon	A platform that moves and maps data between many systems
Where the rules live	Your code, sometimes a custom Odoo module	The vendor's code and settings	The middleware's flows and mappings
Hosting constraint	The API works on any hosting; server-side methods need a custom module	Odoo-built connectors work wherever the app is available; Apps Store modules do not run on Odoo Online	None inside Odoo; it reaches Odoo through the API
Plan constraint	On a paid Odoo subscription, only the Custom plan includes external API access	Only if the connector calls the external API	Same rule as the direct API
Best for	One or two flows with exact business rules	Common pairings where your process matches what the connector does	Many systems, or flows a non-developer team must change
Who maintains it	You, or the provider you hire	The vendor, on its own schedule	The vendor maintains the platform; you maintain the mappings
Upgrade exposure	Adapted by you at each Odoo version	You wait for the vendor's build	Depends on which Odoo API the middleware's connector uses

Sources: Odoo external JSON-2 API (plan restriction, endpoint, transactions) and Odoo Online documentation (custom modules and Apps Store modules are not supported on Odoo Online).

Route 1: a direct integration through the JSON-2 API

On Odoo 19 and 20, the documented way in is the External JSON-2 API: a program POSTs JSON to /json/2/<model>/<method> with an API key as a bearer token. The model is a technical name such as sale.order and the method is one that model exposes, so the API reaches the same business logic the screens use. Each database lists its own models, fields and methods on its /doc page.

Four details from the documentation shape how a direct integration should be built.

The integration acts as a user. Odoo states that all operations are validated against the access rights, record rules and field accesses of the user who owns the API key. For automated integrations it recommends dedicated bot users: give the bot the minimum permissions it needs, leave its password empty so it cannot log in through the login screen, and the access log then shows the bot, not a person. An integration running on an administrator's personal key can do anything that administrator can, under their name.

Keys expire. An API key cannot be created for more than three months, so a long-running integration needs its key rotated at least once every three months. Odoo also recommends one key per integration. Rotation is a recurring task with an owner, not a setup step.

Every call is its own transaction. This detail most often decides the design. Odoo states that each JSON-2 call runs in its own SQL transaction and that several calls cannot be chained into one. It warns that this is especially dangerous for operations such as reservations and payments, and that the fix is to call a single method that does all the related work. Some business steps already fit one call: create on a sales order can carry its order lines as x2many commands, and search_read searches and reads in one transaction. When a step has no standard single method (create the order, reserve stock, register the payment, all or nothing), the clean answer is a server-side method in a custom module. Custom modules cannot run on Odoo Online, so a flow like that on Odoo Online has to be redesigned around standard methods and automation rules, or the integration has to detect and repair half-finished work.

Webhooks handle the other direction. Odoo's webhook documentation describes automation rules with the On webhook trigger: an external system POSTs a payload to the rule's URL and Odoo runs an action. Creating a record (rather than updating one) needs the Execute Code action, and Log Calls keeps a request history. Rules can also send data out to an external webhook when a record changes. The page warns that a misconfigured webhook may disrupt the database and take time to revert, and tells you to build and test it on a duplicate database first.

A direct integration fits one or two flows with exact rules, near-real-time needs, and someone who will own the code through every upgrade.

Route 2: a prebuilt connector

"Connector" covers three quite different things, and the difference matters for maintenance.

Connectors built into Odoo. Odoo ships integrations it maintains and upgrades with each release. The payment providers list includes Stripe, PayPal, Adyen, Mollie and Authorize.Net, among others. The shipping connectors include DHL Express, FedEx, UPS, US Postal Service, Sendcloud and EasyPost; the same page notes that other DHL services are not supported. The Amazon Connector synchronizes confirmed FBA and FBM orders from Amazon into Odoo, creates missing customers, notifies Amazon of shipments confirmed in Odoo for FBM orders, sends available quantities to Amazon for FBM, and supports several seller accounts and marketplaces. They are the safest to depend on, but do exactly what their feature lists say and nothing more.

Modules installed in your database. Third-party connectors from the Odoo Apps Store, or from a connector vendor, run inside Odoo. They can do things the external API cannot, such as multi-step server-side transactions, but they do not run on Odoo Online, and every Odoo upgrade waits for the vendor's build for the new version.

Connectors hosted by a vendor. A service outside Odoo that works through the external API, so on a paid Odoo subscription it needs the Custom plan (the only one that includes external API access), a bot user and key rotation like any direct integration.

Before you commit to any connector, check it against your own flows:

• Each flow you need is on its feature list, with its direction stated (the Amazon Connector, for example, brings orders into Odoo and sends quantities out only for FBM).
• The fields you rely on travel with it: taxes, shipping charges, discounts, refunds, lot or serial numbers.
• A build exists for your Odoo version, and the vendor has a stated plan for the next one.
• It shows failed records somewhere a user will see them, and can re-run one without creating a duplicate.
• You know which Odoo API it calls (see the deadline section below).
• You know what happens to your data and settings if you stop using it.

Our marketplace integration pages describe the channels we connect, such as Shopify, Amazon, eBay and WooCommerce, and what each connection covers.

Route 3: middleware

Middleware (an integration platform, or iPaaS) sits between Odoo and your other software and holds the flows and field mappings in one place. It earns its keep when several systems exchange data and would otherwise each need a connection to every other, when your company already runs one, or when an operations team rather than developers must change mappings.

It also adds costs that are easy to miss when choosing:

• another subscription, and another place where business rules live, separate from Odoo and from the other systems;
• debugging that spans three systems instead of two;
• the same Odoo constraints as any API client: on a paid Odoo subscription the Custom plan, a bot user, a key that expires every three months at the latest, and one transaction per call. A middleware flow that makes four Odoo calls to build one order has the same half-written-order risk as a hand-written script;
• an Odoo connector inside the middleware that may still use the deprecated XML-RPC endpoints.

For one storefront and one carrier it is rarely the right first step.

Five questions that decide the route

Answer these in order; each one rules options in or out.

1. Where is Odoo hosted? On Odoo Online, custom and Apps Store modules are out, leaving Odoo-built connectors, the API, webhooks and anything outside Odoo. On Odoo.sh or your own servers, every route is open.
2. Which plan are you on? Odoo's documentation states that external API access is only available on Custom pricing plans, not on One App Free or Standard. If any route you are considering calls the API, confirm the plan before the project is priced.
3. Must several writes succeed together? If a business step needs more than one write and no standard method does it in one call, you need either a server-side method (a module, so not Odoo Online) or an integration designed to detect and repair partial work.
4. How much data, and how fast? Events needed within seconds suit webhooks; nightly or hourly batches suit scheduled jobs. Polling a large catalogue every few minutes is where weak designs get slow.
5. Who owns it in year two? Someone must rotate keys, adapt code or mappings at each Odoo upgrade, and work the failure list. If no one on your side will, buy that work explicitly.

The XML-RPC deadline: audit what you already run

Many existing integrations use the older XML-RPC and JSON-RPC endpoints. The Odoo 20.0 documentation states that the db service of those APIs was removed in Odoo 20 (fall 2026) and Odoo Online 19.1 (winter 2025), and that the common and object services are scheduled for removal in Odoo 22 (fall 2028) and Odoo Online 21.1 (winter 2027). The other type='jsonrpc' routes, such as those used by website pages, are not covered by that notice. Odoo Online databases reach the cutoff earlier than Odoo.sh and self-hosted ones.

The audit has four steps:

• list every system that reads from or writes to Odoo, including scripts someone wrote years ago;
• for each, find out which endpoint it calls: /xmlrpc, /xmlrpc/2, /jsonrpc or /json/2;
• for anything on the old endpoints, get the vendor's migration date in writing, or plan the move to JSON-2 yourself;
• check whether anything created, copied or dropped databases through the db service, because on Odoo 20 that has already stopped working.

What goes wrong, and how to spot it

Duplicates after a retry. A call times out and the retry repeats work the first call had done. Symptom: two sales orders with the same marketplace reference. Ask how the integration recognises a record it has already processed.

Half-written records. Symptom: orders without lines, or confirmed documents missing their follow-up steps. The usual cause is the one-transaction-per-call rule above.

Sync stops on a date. Symptom: every call fails with 401 Unauthorized: Invalid apikey. The key expired; give its rotation date a named owner.

An integration that can do everything. Symptom: integration changes appear under a person's name, or the integration can see payroll. Move it to a dedicated bot user.

Mapping drift after an upgrade. Symptom: after an upgrade, sync errors name a field or value. Include an integration run in every upgrade test on the duplicate database.

Silent failures. Symptom: users find missing orders before the integrator does. Every integration needs a failure list someone reads, and a way to re-run one record.

A scoping checklist for any Odoo integration

Whatever the route, the specification should state:

1. each flow, with its direction, trigger and frequency;
2. the system of record for each shared field (who wins when Odoo and the other system disagree);
3. the external reference that makes each record unique, and how retries use it;
4. which writes must succeed together, and the single method or module that does them;
5. the integration user, its access rights, and the owner and date of each key rotation;
6. hosting and plan, confirmed against the route;
7. the API used (JSON-2 for new work on Odoo 19 and 20);
8. how failures are shown, re-run and reported;
9. the test plan on a duplicate database, and the plan for the next Odoo upgrade.

Where Odovation fits

Our Odoo integration service follows this guide's order: settle hosting, plan and ownership, then choose per flow, using an Odoo-built connector where it covers the process, the JSON-2 API or a module where rules are exact, and middleware only when enough systems justify it. Integration is also one of the layers in a wider development project; our guide to what Odoo development services include covers how integrations interact with custom modules, data migration and upgrades. To check an integration you suspect is still on XML-RPC, or a proposal against the questions above, use our contact page.

Frequently Asked Questions

Does Odoo have a REST API?

The external API Odoo documents for versions 19 and 20 is the JSON-2 API: JSON sent by HTTP POST to /json/2/<model>/<method> with an API key as a bearer token. Any HTTP client can call it, but it is not REST in the resource-per-URL sense, because every URL names a model and a method.

Can Odoo Online be integrated with other systems?

Yes: through the external API (on a paid Odoo subscription, only the Custom plan includes it), webhooks built as automation rules, Odoo's built-in connectors, and connectors or middleware hosted outside Odoo. What it cannot run is custom modules or Apps Store modules, so logic that must run inside the database has to fit standard methods and automation rules.

How often do Odoo API keys need to be rotated?

At least every three months, because Odoo does not allow keys that last longer than that. Use a separate key for each integration so that one can be revoked without breaking the others.

Will my existing Odoo integration stop working?

If it calls /xmlrpc, /xmlrpc/2 or /jsonrpc, it will at some point. Odoo's documentation schedules those endpoints for removal in Odoo 22 (fall 2028) and Odoo Online 21.1 (winter 2027), and the db service was already removed in Odoo 20. Ask the vendor or developer which endpoint it uses and when it moves to JSON-2.