In these docs

Execution Layer for Odoo

Connections and the Context Layer.

The Connections screens of the Execution Layer: one row per AI client per user, revoke that works instantly, API keys with their own scopes, self-registered OAuth clients, and the Context Layer activation form.

Available now · Odoo 19 Updated 19 September 2026

A connection is the unit people see and control: one AI client, signed in as one user. This page walks the Connections menu, where every AI that can reach your Odoo is visible, inspectable, and revocable.

The connections list

One row per AI client per user: who is connected, as whom, with what effective permission, from where.

Each row shows the AI client’s name, the kind (OAuth or API key), the user it acts as, the effective permission in plain words (“full (as bundle allows) · all allowed models”), last use, last IP, calls today, live sessions, and two actions:

  • Revoke kills the connection immediately. The client’s token stops working on its very next call.
  • Permissions opens the per-connection controls the user chose at consent (access level and an optional model subset), which can be narrowed later at any time.

Users see only their own connections. Administrators see everyone’s. This is enforced by record rules, not by hiding menus: a plain user asking over RPC is refused the same way.

The sub-screens

  • API keys. A user can mint a key that acts as themselves, for non-interactive clients and scripts. Each key carries independent scopes (read, create, update, delete, execute, export), an optional IP allow-list, and an expiry. A key is never broader than the user’s own rights.
  • Registered AI clients (admin). The OAuth clients that registered themselves via dynamic client registration. Registration can be turned off in Settings.
  • OAuth sessions (admin, advanced). The live tokens, for auditing and troubleshooting.

How a client connects

  1. The Setup guide hands you a copy-paste snippet per client (Claude Code, Claude Desktop, ChatGPT, Cursor, generic MCP). The endpoint is always https://<your-odoo>/nanti/mcp.
  2. The client runs the OAuth flow (OAuth 2.1: PKCE, dynamic client registration, refresh-token rotation). The user signs in as themselves and consents, choosing an access level and, optionally, a model subset.
  3. A Connection row appears. A first governed read works immediately; writes stay off until an administrator enables them globally.

Per-client specifics live in connecting an AI client.

The Context Layer connection

One field that matters: the activation key. The status stepper (Not connected, Connected, Degraded) is never stale, and the data-flow note is explicit.

The Context Layer for Odoo is the one add-on: verified business meaning, served to your AI before it acts. Its connection screen (Connections → Context Layer, admin) has one input that matters: the activation key you get from nanti.ai. There is no separate token field; the key is exchanged for a runtime credential that is sealed at rest and never shown to anyone, AI clients included. The tenant fills itself in after activation.

  • Start 7-day trial begins the full trial on the spot, no card.
  • Test connection and the three-step status (Not connected → Connected → Degraded) always reflect reality; the view reloads after every action so the status is never stale.
  • The data-flow note on the form is the contract: only your Odoo version and edition, installed module names, model and field names, and business terms ever leave the server. Customer records never do. Every outbound call is recorded in Evidence, and the pipeline never waits on the Context Layer.

Lapse-safe, by design

If the subscription ends, the key is disabled, the connection honestly shows degraded or not connected, cached meaning entries keep serving, and the Execution Layer keeps working. No feature is crippled to force an upgrade.

Next: users, bundles, and rules, where an administrator decides who may do what.