Connect Odoo to n8n.
n8n ships an Odoo node, but it reaches four resources — Contact, Note, Opportunity and Custom Resource. Most real ERP automation runs past that in the first week. Here are the three paths that work, in the order you should try them, and the Odoo plan check that decides whether any of them can.
Check the Odoo plan, or nothing below will work
n8n's own Odoo credential documentation says it plainly: access to the external API is only available on a Custom Odoo plan — the One App Free and Standard plans will not give you access. That single line kills more n8n–Odoo projects than any node limitation, and people usually discover it after building the workflow.
So settle it first. If you are on Odoo Online Standard, no n8n node, no HTTP request and no MCP server can reach your data, because there is no API on the other end to reach. Your options are to move to Custom, move hosting, or self-host Community — where the API is included and there is no plan to upgrade. The full cost of that gate is in what Odoo API access really costs: roughly $61 per user per month at renewal against about $31, so around $8,970 a year extra for 25 people to enable one integration.
Self-hosted Community, Odoo.sh, and Odoo Online Custom all have the API. Everything below assumes one of those.
Pick the integration shape before you open n8n
There are three genuinely different ways to connect Odoo and n8n, and most of the frustration people report comes from starting on the first one and needing the second.
| Built-in Odoo node | HTTP Request node | MCP Client Tool node | |
|---|---|---|---|
| What it reaches | Contact, Note, Opportunity, Custom Resource | Any model, any method | Whatever your MCP server exposes |
| Setup effort | Lowest — fill in a credential | Moderate — you write the calls | Moderate — you run a server |
| Odoo 19 JSON-2 | Via the node’s own transport | Yes, directly | Yes, if the server speaks it |
| Good for | CRM-shaped automations | Anything the node cannot express | AI agent workflows |
| Where it breaks | The four-resource ceiling | You own the auth and error handling | Another service to host |
1. The built-in Odoo node
n8n ships an Odoo node with four resources — Contact, Note, Opportunity and Custom Resource — each supporting Create, Delete, Get, Get All and Update. Credentials are Site URL, Database name, Username, and Password or API key. Use the API key: generate it in Odoo under Preferences → Account Security → Developer API Keys, and never wire a workflow to an administrator password.
Read that resource list again, because it is the whole story of this node. Three named resources, all CRM-shaped. No sale order, no invoice, no stock move, no product, no manufacturing order. If your automation is "when a form comes in, create a lead," the node is perfect and you are done in ten minutes. If it is anything to do with the warehouse or the ledger, you are already on the Custom Resource path.
2. Custom Resource, and why people give up on it
Custom Resource is the escape hatch: name any Odoo model and run the same five operations against it. It genuinely works, and it is the right answer for a lot of workflows. What it does not do is help you with the shape of Odoo's data. You supply field names, you supply the domain, and you find out at runtime that partner_id wants an integer id rather than a name, that a required field you never heard of blocks the create, and that Get All without a limit will happily try to return the whole table.
Two habits fix most of that. Build the domain and the field list against the Odoo API in isolation first — one call, one model — and only then paste it into n8n. And always set a limit on Get All, even in testing, especially in testing.
3. HTTP Request against the API directly
When the node cannot express what you need — batched writes, a workflow method like confirming an order, a read_group aggregation — drop to the HTTP Request node and call Odoo's external API yourself. On Odoo 19 that is JSON-2: POST /json/2/{model}/{method} with an Authorization: bearer header and named arguments. On 18 and 17 there is no /json/2 — you are on XML-RPC or JSON-RPC, and the request bodies look nothing alike. The differences, side by side.
This is more work and it is worth it more often than people expect. You get every model and method, you can batch, and the failure messages come straight from Odoo instead of through a node's error mapping.
The MCP path: when n8n is driving an agent
If the point of the workflow is an AI agent that answers questions about the business rather than a fixed sequence of steps, the node approach inverts. You do not want to pre-wire every Odoo call — you want to hand the agent a set of tools and let it choose.
n8n has both halves of MCP. The MCP Client Tool node connects an n8n agent to an external MCP server and exposes that server's tools to the model; it supports Bearer, generic-header, multiple-header and OAuth2 authentication. The MCP Server Trigger node does the reverse — it publishes your n8n workflows as MCP tools for an outside client such as Claude or ChatGPT — over SSE or streamable HTTP, though not stdio.
So for Odoo there are two sensible arrangements:
- n8n agent → Odoo MCP server. Point the MCP Client Tool node at an Odoo MCP server. The agent gets search, read and — if you allow it — write tools, with the access control living in the server rather than scattered across nodes. This is the arrangement to want if the agent needs to reason over ERP data.
- AI client → n8n → Odoo. Use the MCP Server Trigger to expose a small number of curated n8n workflows as tools. Good when you want the AI to trigger processes you have already designed, rather than query raw models.
The operational detail that bites
The MCP Server Trigger needs a persistent connection, and that assumption breaks quietly in two common deployments. If you run n8n in queue mode with multiple webhook replicas, route every /mcp* request to one dedicated webhook replica — otherwise connections land on different processes and drop. And behind nginx or a similar reverse proxy, disable proxy buffering for that endpoint, or the stream will be held and delivered in chunks that look like the server hanging. Neither failure produces a useful error message; both look like "MCP is flaky."
Which Odoo MCP server to point at is its own decision — the open-source field, compared, and the security posture to hold either way is in the Odoo MCP security checklist.
Set this up once, properly
Whichever path you take, the Odoo side is the same and it is worth doing correctly the first time. A workflow automation platform holding an administrator key is a bad afternoon waiting for a trigger.
- Create a dedicated Odoo user for n8n. Not a person's account, not admin. Name it so it is obvious in the log —
svc_n8nbeatsintegration2. - Give it the narrowest groups that let the workflow run, then add record rules if the automation should only see part of the data. Odoo's own permission model is the strongest gate you have; do not skip it because the node made it easy not to.
- Generate an API key under Preferences → Account Security → Developer API Keys, as that user, and use it instead of a password. On Odoo 19, note that API keys have a maximum duration — put the expiry in a calendar before it puts itself in your incident log.
- Store it in an n8n credential, never in a node parameter or an expression. Site URL, Database name, Username, API key.
- Test read before you test write. One Get All with a limit of 5, against one model. If that works, the plan, the credential and the network are all fine, and every later failure is a workflow bug.
The four errors you will actually hit
- Authentication fails and the credentials are right. Nine times in ten the database name is wrong, not the password. It is the instance name, and on a multi-database server it must match exactly. On Odoo Online it is not the part of the URL you assumed.
- Everything 404s or the API “does not exist”. Check the plan first — Standard has no external API — and then check the version.
POST /json/2/…is Odoo 19; on 18 and 17 that path does not exist and the 404 is correct behaviour, not a bug. - Create fails on a required field you have never seen. Odoo models have required fields that the form view fills in for you and the API does not. Read the model’s fields once, note the required set, and supply them explicitly.
- The workflow gets slower every week. Almost always a Get All without a limit against a table that is growing. Set limits, filter with a domain, and aggregate in Odoo with
read_grouprather than pulling rows into n8n to count them.
A useful diagnostic habit: when something fails, reproduce it as a single API call outside n8n. If the raw call works and the node does not, it is a mapping problem; if the raw call fails too, n8n was never the issue.
FAQ
Does n8n have an Odoo integration?
Yes. n8n ships a built-in Odoo node supporting four resources — Contact, Note, Opportunity and Custom Resource — each with Create, Delete, Get, Get All and Update. Anything outside those you reach through Custom Resource, the HTTP Request node, or an MCP server.
Why can n8n not connect to my Odoo Online database?
Almost certainly the plan. n8n’s own documentation states that Odoo’s external API is available only on the Custom plan — One App Free and Standard do not provide it. Self-hosted Community includes the API at no charge.
What credentials does the n8n Odoo node need?
Site URL, Database name, Username, and a password or API key — with the API key recommended. Generate it in Odoo under Preferences → Account Security → Developer API Keys, as a dedicated service user rather than an administrator.
Can n8n create a sale order or invoice in Odoo?
Not through the named resources — they cover CRM objects only. Use Custom Resource with the model name, or the HTTP Request node against the external API, which also lets you call workflow methods such as confirming an order.
Does n8n support MCP?
Yes, both directions. The MCP Client Tool node lets an n8n agent call an external MCP server’s tools, with Bearer, header or OAuth2 authentication. The MCP Server Trigger node publishes n8n workflows as MCP tools over SSE or streamable HTTP — stdio is not supported.
Why does my n8n MCP Server Trigger keep dropping connections?
It needs a persistent connection. In queue mode with multiple webhook replicas, route all /mcp* requests to one dedicated replica; behind nginx, disable proxy buffering for that endpoint. Both failures look like flakiness rather than configuration.
Should I use the Odoo node or the HTTP Request node?
Start with the node — if the automation is CRM-shaped it is ten minutes of work. Move to HTTP Request when you need batched writes, workflow methods, aggregation, or clearer errors straight from Odoo.
Related reading
Give the agent tools, not a database password.
Odin's Odoo MCP server answers as the signed-in user and logs every question. Point n8n's MCP Client Tool at it, or try the sandbox first.