> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # Odoo > Connect your Odoo database to Oleria to discover users, API keys, access groups, roles, the business models each group can access, company access, and sign-in and record-change activity. Connect Odoo to Oleria to see who has access to your Odoo database and what they can do in it. Oleria reads users, access groups, roles, and access rights through the Odoo External API with the API key of a dedicated Odoo administrator. You can see which groups can read, write, create, or delete records of each business model, such as journal entries or employees, find over-privileged access, and act on it directly from Oleria. This integration supports Odoo 16.0 or later on Odoo Online, Odoo.sh, and on-premise databases. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Odoo database: * **Users** - every Odoo user, with name, login, email address, company, and status. Archived users are shown as disabled. Internal users are shown as standard users, portal users as external users, and the public website user as an anonymous user. Users with an enrolled authenticator app, or covered by your two-factor enforcement policy, are shown with multi-factor authentication required. Users linked to an OAuth sign-in provider are shown with single sign-on configured. Oleria also shows passkeys, the last sign-in or activity date, and who created each user. * **Non-human identities** - every API key, as a personal access token owned by the user it belongs to, with its name, scope, creation date, and, on Odoo 18 and later, expiry date. An API key acts with all the permissions of its user. Oleria never sees a key's value. Odoo's system identities, such as OdooBot (the superuser) and the template users Odoo copies new users from, are shown as system identities. * **Access groups** - every group, its members, and the groups it implies, so you can see access a user inherits through another group. * **Roles** - Odoo's user roles (Administrator, User, Portal, and Public, plus Light on Odoo 20) and who holds each. * **Resources and access** - the business models that a group can read, write, create, or delete, and your companies and branches with the users allowed in each. On Odoo 16 to 19, an access right that isn't tied to a group applies to every user, so Oleria shows it on every role. * **Database managers** - a group named **Odoo database managers (synthesized)** stands for the people who control the database outside Odoo, such as the database managers on odoo.com, Odoo.sh collaborators, or whoever holds the master password of an on-premise server. Odoo's API doesn't list these people, so the group has no members. * **Activity** - sign-ins, changes to tracked fields on business records, other record notifications such as stage changes (shown as custom activity), API key creation, and user creation. On Odoo 18 and later, each sign-in session is shown with its IP address and location, and on Odoo 18 and 19 also with its browser. Oleria refreshes this data on its [regular sync schedule](https://docs.oleria.com/integrations/overview.md#sync-model). Oleria doesn't import individual records such as invoices or sales orders. ## Prerequisites * An Odoo database on Odoo 16.0 or later. On Odoo Online, the database must be on the Odoo Custom plan, because Odoo offers the External API only on Custom, not on One App Free or Standard. Odoo.sh and on-premise databases can be used as they are. * A dedicated internal Odoo user for Oleria, with the Administrator role and access to every company. See [Create the Odoo API user](#create-the-odoo-api-user). * An Odoo URL that Oleria can reach over HTTPS. Odoo Online and Odoo.sh databases at `https://.odoo.com` are reachable as they are. If your Odoo uses a custom domain or is self-hosted, contact [support@oleria.com](mailto:support@oleria.com) to allowlist its hostname before you connect. Oleria doesn't connect to private or loopback addresses. * Admin access to the Oleria workspace. ### Permissions Oleria needs Oleria needs the user's **Settings** access right under **Administration** (`base.group_system`). On Odoo 19 and later, this is the **Administrator** role. The user must also have every company, including archived ones, in its **Allowed Companies**. Below these permissions, Odoo hides some users, other users' API keys, sign-in logs, and system settings from the API user. Oleria would then see only part of your users, and the missing ones would look deleted. So Oleria refuses to connect, sync, or run actions with a user that isn't an administrator or isn't allowed in every company. ## Create the Odoo API user **1. Create a dedicated user** In Odoo, go to **Settings** -> **Users & Companies** -> **Users** and create an internal user for Oleria, for example `oleria-api`. **2. Grant the Administrator role and every company** Under **Administration**, give the user the **Settings** access right. On Odoo 19 and later, set its role to **Administrator**. Add every company to the user's **Allowed Companies**. **3. Create an API key** Sign in as that user, open **Preferences** -> **Account Security**, select **New API Key**, and copy the key. On Odoo 18 and later, a key created by an administrator can be persistent. Otherwise, Odoo expires it within 90 days, and you need to update the integration with a new key. On Odoo 16 and 17, API keys don't expire. > [!WARNING] > > Treat the API key like a password. Anyone who has it can act in Odoo with all of the Administrator's permissions. > [!NOTE] > > The exact location of these settings can change between Odoo versions. If the steps above don't match what you see, refer to Odoo's own documentation. ## Connect Odoo to Oleria **1. Find Odoo in Oleria** Go to your Oleria workspace, select **Integrations**, select the **Available** tab, and search for **Odoo**. **2. Complete the connection form** Select the **Odoo** card and fill in the form: | Field | Description | | :- | :- | | Odoo URL | Required. Your Odoo address over HTTPS, for example `https://mycompany.odoo.com`. Enter the address without a path. Oleria also accepts an address ending in `/odoo`, `/web`, or `/web/login`. | | Database name | Required. The name of your Odoo database. On Odoo Online, it's usually the sub-domain of your Odoo URL. | | Login (user email/username) | Required. The login of the Odoo API user, for example `oleria-api@mycompany.com`. | | API key | Required. The API key you created for that user. | **3. Authenticate** Select **Authenticate**. Oleria checks that the database runs Odoo 16.0 or later, that the API key belongs to the login you entered, and that the user is an administrator allowed in every company, before it saves the connection. ## Verify the integration Confirm the new instance appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, you can review the discovered users, API keys, groups, roles, and activity in your Oleria workspace. > [!NOTE] > > When you edit the integration, you can change its fields and select **Update**. Leave **API key (optional)** blank to keep the stored key, and enter a new key only when you rotate it. You can move the integration to a new Odoo URL, for example after a domain change, but not to a different database. To connect another database, add a new integration. If Oleria can't connect, check the error message: * `Odoo rejected the login and API key` or `Odoo rejected the API key`: check the database name and the login, and that the key hasn't expired or been revoked. * `could not reach the Odoo database at `: check the Odoo URL. If your Odoo uses a custom domain or is self-hosted, check that its hostname has been allowlisted, as described in [Prerequisites](#prerequisites). * `Odoo is not supported: the connector needs Odoo 16 or later`: upgrade the database to Odoo 16.0 or later. * `Odoo refused the API call (HTTP ); the external API requires the Odoo Custom plan on Odoo Online`: on Odoo Online, check that the database is on the Odoo Custom plan. * `the Odoo API key's user is not an Administrator` or `the Odoo API key's user is not allowed in every company`: update the user as described in [Create the Odoo API user](#create-the-odoo-api-user). * `the Odoo API key could not be verified`: on Odoo 19 and later, check that the login is the one of the user who owns the API key. * `the URL and database now point at a different Odoo database`: when you edit the integration, the URL and database name must still lead to the database you first connected. To connect another database, add a new integration. ## Remediation actions Beyond discovery, Oleria can act on Odoo access to remediate risk. Every action needs the permissions described in [Permissions Oleria needs](#permissions-oleria-needs). | Action | What it does | Reversible? | | :- | :- | :- | | **Disable user accounts** | Archives the user. An archived user can't sign in, and every API key the user holds stops working. | Yes - reactivates the user, if they're still archived. | | **Enable user accounts** | Reactivates an archived user. | Yes - archives the user again, if they're still active. | | **Add user to group** | Adds the user to an access group. The groups behind Odoo's roles are refused: use **Add user to role** instead. Odoo refuses a group meant for another user type, such as an internal-user group for a portal user. | Yes - removes the membership the action added. On Odoo 16 to 18, it also removes the implied groups that the add brought with it. | | **Remove user from group** | Removes the user from an access group. The groups behind Odoo's roles are refused: use **Remove user from role** instead. If any other group the user holds implies the group, the action fails and names those groups, even when the user was also added to the group directly, because Odoo would keep the group through them. Remove the user from those groups instead. On Odoo 16 to 18, it also removes the groups that come with the group, unless another group the user keeps still implies them. It never removes a role group. | Yes - adds the user back to the group. | | **Add user to role** | Gives an internal user the Administrator role. Only the Administrator role can be assigned, because the other roles change the user type. | Yes - removes the Administrator role again. | | **Remove user from role** | Removes the Administrator role. On Odoo 16 to 18, it also removes the other groups that came with the Administrator role, unless another group the user keeps still implies them. On Odoo 19 and later, Oleria gives the user the User role in the same change, so they stay an internal user. If the user is an Administrator through another group, the action fails and names that group. | Yes - gives the user the Administrator role again. On Odoo 19 and later, the user keeps the User role that the action added. | | **Revoke permission to resource instance** | Removes a company from the user's **Allowed Companies**. Oleria refuses the user's current company, because Odoo requires it in the Allowed Companies. Access to a business model always comes from groups, so to remove it, use **Remove user from group**. | Yes - adds the company back. | | **Create user** | Creates an internal user with the name and email address you choose. The email address is the user's login. Oleria doesn't set a password. The user is created archived unless the action activates it. If you choose groups, the user gets the User role and those groups. If a user with that login already exists, the action fails. | Yes - deletes the created user, as long as it still has the same login. If Odoo refuses to delete the user because records refer to it, Oleria archives the user instead and says so. | | **Delete user** | Deletes the user. If Odoo refuses because records still refer to the user, the action fails. Archive the user with **Disable user accounts** instead. | No - a deleted user can't be restored. | | **Create group** | Creates an access group with the name you choose. If a group with that exact name and no application already exists, Oleria makes no change. | Yes - deletes the group, as long as it still has the same name and no members. | Keep these limits in mind when you use these actions: * Oleria reads the user or group before it changes anything. If it's already in the requested state, Oleria makes no change, and reverting the action makes no change either. **Create user** is the exception: it fails if a user with that login already exists. * After it changes an existing user's status, groups, role, or companies, Oleria reads the user again to confirm Odoo applied the change. If Odoo accepted the change but the new read shows it didn't apply, Oleria undoes the change and the action fails. **Create user**, **Create group**, and **Delete user** don't undo anything: if the new read doesn't confirm the change, the action fails, and a failed **Create user** or **Create group** may still have created the user or group in Odoo. * Reverting an action undoes only the change that action made. If the user no longer exists, or is already back in its earlier state, the revert makes no change and says why. Reverting **Add user to group** or **Remove user from group** fails if the group has been deleted. On Odoo 16 to 18, reverting **Add user to group** also fails if the user now holds the group through another group. * Oleria won't archive, delete, or change the groups, role, or companies of the connection's own user, because that could disconnect the integration. * Oleria won't change Odoo's system identities: OdooBot, the public website user, and the template users. * Oleria can't change the **Odoo database managers (synthesized)** group. Manage those people on odoo.com, in Odoo.sh, or on your Odoo server. * Creating an active user or enabling a user can add a paid user to your Odoo subscription. A user created archived doesn't use a seat until it's enabled. * Oleria can't revoke an API key or end a user's sessions. See [Known limitations](#known-limitations). ## Known limitations * **Record rules aren't reflected.** Oleria shows access at the business-model level, from the groups' access rights. Odoo record rules can narrow that access further, for example to the user's own company or documents, and Oleria doesn't subtract them. * **No failed sign-ins or access-right changes in activity.** Odoo doesn't record failed sign-ins or changes to groups, access rights, or two-factor settings in a form Oleria can read. * **Sign-in history on Odoo 16 and 17.** Before Odoo 18, Odoo keeps only each user's latest sign-in, so Oleria can't import a full sign-in history. * **No changed field names on Odoo 20.** Odoo 20 no longer exposes which fields a record change touched, so Oleria shows the change without the field names. * **No API key last-used date or password change date.** Odoo doesn't record when an API key was last used or when a user last changed their password. * **License level isn't available.** Odoo bills active internal users but doesn't expose a seat field in its API. * **API keys and sessions can't be revoked from Oleria.** Odoo requires an interactive password check to revoke an API key or end a user's sessions. To stop a user's API keys, archive the user with **Disable user accounts**. ## Contact us For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.