Connect your Odoo to Claude with an API Key and build your own views without writing Python

A thread in the Odoo Mexico Facebook group reminded us of something uncomfortable: the open source community had already solved this problem before the consultant showed up to quote thousands of dollars. Here is the how, for any version and any edition of Odoo, and here are the downsides almost no one tells you about.

The spark: a fair question and eight expensive answers

In the Odoo Mexico Facebook group, someone asked what many of us have thought at some point (originally in Spanish):

"Who has a module to query reports with AI for Odoo Community?"

The answers were predictable: "happy to build it for you," "we already have one up and running," "hi, we can gladly help you," "we can do it for you at a good price." A community doing what it does best: quoting.

And in the middle of the thread, the answer that is rarely said out loud:

"Why not just generate the API Key and hand it to any AI agent so it sets up the MCP connection and builds your custom views?"

Any version of Odoo. Any edition. Without installing third-party modules. Without quoting anything. Without writing a single line of Python.

This article is the long, honest version of that answer. With the step by step, yes, but also with the fine print most posts skip: the technical debt you introduce, the dependence you create, the Odoo charges you can trigger without realizing it, and why this does not replace a good consultant, it empowers one.

What Odoo already ships out of the box and almost no one uses

Before the tutorial: for years Odoo has shipped, inside the Technical menu, a toolbox most users do not know exists:

• Custom views: list, kanban, form, pivot, graph, calendar.
• Fields: add computed or related fields to existing models.
• Models: inspect the real structure of the data.
• Menu items: hang your views somewhere visible.
• User filters: save the filter you use every Monday.

None of this needs Python. It is composed with XML and QWeb, which is HTML with superpowers. If you ask a language model to write that view for you, it writes it without trouble, because the public Odoo corpus has been full of exactly that for more than a decade.

The "AI module for reports" they will quote you for thousands of dollars is, in most cases, exactly this wrapped in a manifest.

Diagram source (Mermaid)

mindmap
  root(("Odoo
Technical menu"))
    User interface
      Custom views
      Menu items
      User filters
    Data structure
      Models
      Fields
      Field selection
    All without Python
      XML and QWeb

Diagram source (Mermaid)

flowchart LR
    U(["User"]) -->|"1. Generate"| K["API Key in Odoo\nProfile, Preferences, Security"]
    K -->|"2. Configure"| M["AI agent + MCP server"]
    M -->|"3. Read real schema"| S[("Models and fields\nfields_get / list_models")]
    S --> M
    M -->|"4. Write"| V["Custom view\nXML / QWeb, no Python"]
    V -->|"5. Verify in browser"| U

Tutorial: how to connect it yourself, step by step

Diagram source (Mermaid)

flowchart LR
    P1["Step 1\nGenerate the API Key\nProfile, Preferences,\nSecurity"] --> P2["Step 2\nConnect the Odoo\nMCP to the agent"] --> P3["Step 3\nDescribe the view\nin plain language"] --> P4["Step 4\nVerify in\nthe browser"] --> P5["Step 5\nSave a record\nof the change"]
    style P4 fill:#E14228,stroke:#E14228,color:#FFFFFF

Step 1: generate your API Key in Odoo

Inside Odoo, with your user: Profile, Preferences, Account or Security tab, New API Key.

Give it a descriptive name (for example, claude-mcp-september2026). Odoo shows you the key only once, so copy it immediately into a password manager. If you lose it, you generate another one; it is not recoverable.

It works on Community, Enterprise, Odoo Online, and Odoo.sh. It works on v14, v15, v16, v17, v18, and v19. It is a native mechanism, not a trick.

Step 2: register an Odoo MCP in your AI agent

MCP stands for Model Context Protocol, the open standard that connects AI agents with real systems.

Choose the connector your stack supports:

• An Odoo MCP server that runs in Docker and exposes the typical operations (odoo_search_read, odoo_fields_get, odoo_list_models, odoo_create, odoo_write, odoo_execute). This is the approach we use internally at Transgenia.
• Lighter XML-RPC wrappers for Claude Desktop, Cursor, or VS Code.

Your MCP needs four pieces of information:

ODOO_URL=https://your-instance.odoo.com
ODOO_DB=your-database-name
ODOO_USER=user-that-generated-the-key
ODOO_API_KEY=the-key-from-step-1

Step 3: describe to the AI what you want, in plain language

A real instruction that works:

"In the Sales module, create a list view of quotations (sale.order in sent state) older than 7 days since creation, grouped by salesperson and by sector tag. Columns: number, customer, salesperson, total amount, days since it was sent. Hang it under the menu Sales, Reporting, Stalled quotations."

The agent will do three things:

1. Query the real schema (fields_get on sale.order) so it does not invent fields.
2. Generate the view XML, the window action, and the menu item.
3. Write it directly through the API, or hand it to you so you paste it manually into Custom views.

Step 4: verify before you believe

This is the step half of the tutorials omit. Before accepting the view as good:

• Open the menu and navigate the view in the browser.
• Confirm the columns show real data (no empty values, no errors).
• Apply the filters and the groupings; make sure they group by what you asked for and not by something similar.

If something looks off, ask the agent to read back the view it just created. Yes, the AI makes mistakes. The difference is that now you fix it in two messages, instead of waiting two weeks on a consulting ticket.

Step 5: save a record of the change

Note somewhere (a document, an internal note) which view you created, with what instruction, on what date, and which user held the API Key. This step seems optional. It is not. The cons section explains why.

The uncomfortable reflection: the rent-seeking of the traditional consultant

This is where the article gets dense, so I will say it plainly.

A senior consultant with ten years in Odoo can read this and feel two things at once:

1. "They are killing my business." Invoices of five, eight, fifteen thousand dollars for a reporting module that an advanced user can clone in an afternoon with an AI agent and an API Key.
2. "Finally I can stop selling this." Because deep down, billing dozens of hours for a custom view was never the work one imagined when studying systems architecture.

The open source community has been recommending this path for years. Custom views, Studio in Enterprise, the JSON-RPC API, XML development without Python: all of it has been in the official Odoo documentation for more than a decade. What changed in 2024 and 2025 was that a tool appeared, AI agents with MCP, that drops the cost of writing that XML from "a consultant with years of experience" to "an advanced user with patience and good questions."

This change does not eliminate serious consulting. Serious consulting is data architecture, process decisions, security, access control, migrations, integration with the SAT and CFDI, fiscal discipline, and ERP governance. All of that still requires a human being with judgment.

What it does eliminate, and not a moment too soon, is rent-seeking consulting: the kind that bills hours for what today is a click, an instruction, and a native menu. The consultants, developers, and technical project managers who cling to that model are going to compete against increasingly autonomous end users. Those who evolve toward governance, architecture, and judgment are going to be paid better than ever, because the market will finally tell the difference.

Diagram source (Mermaid)

flowchart TD
    C["The Odoo consultant's work"] --> R{"What kind of work?"}
    R -->|"Rent-seeking"| X["Billing hours for a view\nor an ad-hoc report"]
    R -->|"Serious"| K["Architecture, security,\nmigration, ERP governance"]
    X --> XD["Absorbed by the advanced\nuser with AI"]
    K --> KP["Still requires\nhuman judgment"]
    style XD fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style KP fill:#14532d,stroke:#3ba55d,color:#FFFFFF

Pros, in short

• Speed: minutes, not weeks.
• No vendor lock-in: you do not depend on a closed module that might not survive the next upgrade.
• Conversational iteration: you ask, you see, you adjust, without the ceremony of tickets.
• Everything inside the core: you do not add third-party Python code to your instance.
• Portability: the view lives in ir.ui.view like any other native view.

Cons: the fine print almost no one tells you about

This section is the real reason this article exists. The pros are already sold to you everywhere; the cons, rarely.

Diagram source (Mermaid)

mindmap
  root(("API Key + AI
in Odoo"))
    Pros
      Speed
      No vendor lock-in
      Conversational iteration
      Inside the core
    Cons
      Technical debt
      Dependence on the machine
      Billable LoC
      Access control

Diagram source (Mermaid)

flowchart TD
    A["You ask the AI for a change"] --> B{"Does it need Python?"}
    B -->|"No: XML / QWeb / view"| C["Safe\nDoes not count as LoC"]
    B -->|"Studio with simple safe_eval"| C
    B -->|"Yes: def / class / import\nin a server action"| D["Odoo counts it\nas lines of code"]
    D --> E{"Are you on Odoo Online\nor Odoo.sh?"}
    E -->|"Yes"| F["May be billable\nby Odoo SA"]
    E -->|"No: Community self-hosted"| G["Not billed,\nbut it is technical debt"]

1. Invisible technical debt

A view created through conversation with AI does not live in a git repository. There is no diff, no peer review, no history of "who changed what and why" beyond the record's write_uid and write_date.

In practice this means that:

• When you migrate versions, those customizations can break silently and no one knows where to look.
• When the instance grows to dozens or hundreds of views created this way, there is no sane way to audit them.
• Automated tests do not cover them, because they do not exist as code in your continuous integration.

It is the equivalent of building on a house with no blueprints: it works, until you have to remodel.

Diagram source (Mermaid)

flowchart LR
    subgraph IA["View created by conversation"]
      I1["No git repository"] --> I2["No diff or review"] --> I3["Migration:\nbreaks silently"]
    end
    subgraph GIT["Module under version control"]
      G1["Lives in git"] --> G2["Diff, PR, tests"] --> G3["Migration:\nreproducible"]
    end
    style I3 fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style G3 fill:#14532d,stroke:#3ba55d,color:#FFFFFF

2. Dependence on the owner's computer

This is the point that gets most underestimated. The API Key lives on your machine: in your local MCP configuration file, in the Claude Desktop config, in your editor's mcp.json. On a specific, physical laptop, one that can die.

Consequences:

• If the AI agent that makes the modifications runs on the laptop of the instance owner, there is no high availability, no backup of the conversation context, and if that machine dies, the "how it was done" is lost.
• It is not a service with a service-level agreement. It is a configuration local to one person's machine.
• If that person leaves the company with their laptop, the organization is left blind about the customizations that were made.

It is different from a third-party module, which at least lives in addons with its manifest, or a change made by an external consultant, who at least leaves a closed ticket and an invoice as a trail.

3. Responsibility toward Odoo: the famous lines of code

This is the point that came up in the original thread and deserves a paragraph of its own.

On Odoo Online (SaaS) and Odoo.sh, modifications are counted and can be billable as customization, according to Odoo SA's commercial model. The practical operating rule:

• Custom views (pure XML, with no Python server action behind them): safe, they do not count as lines of code.
• Studio with simple visual logic (filters, calculations with safe_eval): generally safe.
• Server actions with Python (def, class, import, complex functions): these Odoo does count as lines of code and they are subject to billing.
• Automations with code: same thing.

If you ask the AI to "solve" a complex calculation by writing you a thirty-line Python server action, congratulations: you just generated technical debt and, on top of that, a variable cost with Odoo SA.

A tip that comes from the thread itself: if Odoo tries to charge you for lines of code for customizations, ask them for the audit report without HTML lines, because HTML, XML, and QWeb should not count as Python code, and that report lets you see the raw tally.

4. Access control: the blast radius problem

The Odoo API Key inherits all the permissions of the user who generated it. That is by design. There are no per-operation granular permissions in standard Odoo.

Consequences:

• If the API Key was generated by the administrator, and you give that key to an AI agent running on an MCP server connected to the internet, the blast radius in case of a leak is the entire ERP: invoices, customers, employees, accounting, everything.
• An agent with administrator access can, by accident or through a prompt injection, execute a deletion on critical models.

Non-negotiable best practice:

1. Create a dedicated user, for example [email protected].
2. Assign minimum groups: read-only wherever possible, write only on the models it needs.
3. Generate the API Key from that user.
4. Never use the API Key of an administrator user.
5. Rotate the key every 60 or 90 days.
6. Record which agent and which machine is using it.

Diagram source (Mermaid)

flowchart TD
    subgraph MAL["Risky"]
      A1["Administrator's API Key"] --> A2["The agent inherits\nALL permissions"] --> A3["Blast radius:\nthe entire ERP"]
    end
    subgraph BIEN["Recommended"]
      B1["Dedicated ai-bot user"] --> B2["Minimum permissions,\nonly what is needed"] --> B3["Blast radius:\ncontained"]
    end
    style A3 fill:#7a2018,stroke:#E14228,color:#FFFFFF
    style B3 fill:#14532d,stroke:#3ba55d,color:#FFFFFF

5. Reproducibility and environments

There is no staging-to-production path for a view created through conversation. If your instance gets corrupted and you restore a backup from two weeks ago, all the views created after that date disappear, unless you exported them by hand or documented their source instruction to regenerate them.

In a traditional module under git, a checkout reproduces the state. Here it does not.

6. Knowledge continuity

If the user who conversed with the agent to create the view leaves the company, who knows what instructions they used, what computed fields exist, what depends on what. Without intentional documentation, each customization created this way is a small black box.

7. Schema hallucination

An agent without access to the real schema can invent fields that do not exist. The view compiles badly, or compiles fine but shows empty for everything. Best practice: ask the agent to always validate against the real model before writing. Mature connectors expose that capability; use it.

When to use this pattern and when not to

Diagram source (Mermaid)

flowchart TD
    Q{"What are you going to build?"} -->|"Ad-hoc report,\npilot, prototype"| SI["Go ahead yourself"]
    Q -->|"Critical process, CFDI,\nsecurity, formal go-live"| NO["With professional\nsupport"]
    SI --> SI2["Power user\nwith judgment"]
    NO --> NO2["Consultant + ERP\ngovernance"]
    style SI fill:#14532d,stroke:#3ba55d,color:#FFFFFF
    style NO fill:#7a2018,stroke:#E14228,color:#FFFFFF

When yes:

• Quick pilots, prototypes, proof of value before buying consulting.
• Ad-hoc reports for power users (analysts, controllers, area managers).
• Community self-hosted instances where Odoo SA charges do not apply.
• Internal team exploration and training.

When no, without professional support:

• Critical processes with several users in production.
• Changes that touch security, CFDI, accounting, or fiscal obligations.
• Any change that requires a formal go-live, user training, and a rollback plan.
• Odoo Online instances without having read the customization terms.
• Any situation where the advanced user does not fully understand what the AI just wrote.

The real role of the consultant, the developer, and the technical PM

I will close with this, which is the reason Transgenia publishes this article instead of keeping it to itself.

This technique does not replace the serious consultant. It empowers them to stop charging for consulting on what today is a supervised click.

And it frees the technical project manager and the senior developer for the work that does require judgment and experience:

• Data and process architecture.
• ERP governance: who can do what.
• Migrations between versions without losing customizations.
• Integrations with the SAT, banks, marketplaces, product catalogs.
• Fiscal and CFDI auditing.
• Designing the operating discipline: how changes are documented, how they are tested, how they are deployed, how they are rolled back.

At Transgenia we use exactly this pattern: an MCP connector to Odoo, a dedicated user with minimum permissions, and a human consultant governing what the agent writes. Not to save ourselves billing hours, but to free them toward work that does build long-term value.

If you are going to try it yourself, welcome to the club: you already know how to start. And if it happens that the view breaks production, that Odoo starts charging you for lines of code, or that the API Key leaked, that is exactly when a call is worth it. That, precisely, is the work that does not disappear.

Frequently asked questions

About the author and Transgenia

Efraín Carreón Ortiz is Director General of Centrum Transgenia, a Mexican technology boutique. He holds the official Claude Code badge (Claude Partner Badge) issued by Anthropic, verifiable on Credly.

Transgenia is an OpenAI Select Partner in the OpenAI Partner Network and a registered partner in Anthropic's Claude Partner Network. We run twelve governed AI agents in our own production and support verifiable implementations in healthcare and B2B.

Let's talk: LinkedIn, a 15-minute call, or the contact page.

Keep reading

• How Transgenia runs with governed AI agents: the governance model (draft-first, human sign-off, MCP) behind this pattern.
• Implementing Claude in your company: a phased guide: the full adoption method, from an Anthropic registered partner.
• Our AI solutions and Transgenia as an OpenAI Select Partner.