> ## 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. # Close > Connect your Close CRM organization to Oleria to discover its users, roles, groups, webhook subscriptions, and API key, and the governance events in its event log. Connect Close to Oleria to see who and what can act on your Close organization: its users and the roles and groups that grant their access, the webhook subscriptions that receive its data, the API key Oleria connects with, and the governance events in Close's event log. Oleria connects with a Close API key, and can also deactivate, reactivate, and add users, change a user's role, add and remove users in groups, create groups, and pause webhook subscriptions. > [!NOTE] > > Each integration connects one Close organization. If you have more than one, add an integration for each. See [Multi-instance support](https://docs.oleria.com/integrations/overview.md#multi-instance-support). ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Close organization: * **Users** - every member of the organization, active and deactivated, with name, email, and role. Oleria also shows: * **Status** - active members are shown as enabled, and deactivated members as disabled. * **Administrator status** - users whose role grants **Manage Groups, Users, Billing & Roles/Permissions** (`manage_organization`) are marked as administrators. * **API access** - users whose role lets them create their own API keys (`manage_own_api_keys`) are marked as having API access. * **MFA** - from each user's two-factor authentication (2FA) enrollment. Close 2FA uses an authenticator app (TOTP). A user who has turned on 2FA shows MFA as required, a user who hasn't shows MFA as not required, and any other 2FA state shows MFA as unavailable. * **Last activity** - the time of the user's newest entry in Close's event log in the last 30 days. This is the user's last data change, not their last login. See [Known limitations](#known-limitations). * **Creation date** - when the Close user was created. Close doesn't report when the user joined your organization. * **Roles** - every role in the organization. Each user holds exactly one role. Close's built-in **Admin**, **Super User**, **User**, and **Restricted User** roles are marked as standard roles, and roles you can edit as custom roles. Each role's permissions are shown as entitlements, grouped by area, such as organization administration, API access, data export and bulk actions, and lead data. A role that restricts which leads its users can see says so in its description. A role that appears on a user but isn't in Close's role list is also shown, with that user's permissions. * **Groups** - every group, with its members. Close groups are flat and don't hold roles. A deactivated user who is still in a group keeps that membership. Groups need the Close **Scale** plan or above. * **Non-human identities (NHIs):** | Identity | Shown as | | :- | :- | | Webhook subscriptions | Application, named after the host it sends data to and its ID, such as **Webhook hooks.example.com (whsub\_...)**. Oleria doesn't show the full URL, because it may contain a token. A subscription is enabled while its Close status is active, and disabled while it's paused. Oleria shows its status, pause reason, health status, the Close events it subscribes to, and its creation and update dates. Its signature key appears as a credential, active while the subscription is active. Oleria records only that the key exists, never its value. The user who created the subscription is shown as its owner when that user is a member of the organization. | | The integration's API key | Personal access token, named after its user, such as **Jane Doe API key**, and always enabled. It's owned by the user who created it, can act as that user, and is marked as an administrator when that user is one. Its credential is shown with full authority, because Close API keys have no scopes, and its last use is Oleria's most recent sync. | * **Activity** - governance events from Close's event log: * users added to or deactivated in the organization; * groups created, changed, or deleted; * lead and opportunity exports, when requested and when completed; * bulk deletes, bulk edits, bulk emails, and bulk sequence subscriptions, when started and when completed; * imports started, completed, or reverted; * configuration changes: custom fields, custom activity types, custom object types, and lead and opportunity statuses created, updated, or deleted. Every event keeps its Close event name. Events are attributed to the Close user who made them. An event made by someone who isn't an active or deactivated member of the organization, such as Close staff using Close Support Access or a user who was removed from the organization, has no actor account in Oleria and keeps that person's Close user ID. Events with no user, such as Close system events, are skipped. An event made with any other API key is marked as made with a token, and keeps that key's ID. An event made with this integration's own API key is attributed to the API key NHI, acting as its user. Oleria doesn't import the changed records' contents. Oleria refreshes this data on its [regular sync schedule](https://docs.oleria.com/integrations/overview.md#sync-model). > [!NOTE] > > This integration covers users, roles, groups, NHIs, and activity. It doesn't sync CRM records such as leads, contacts, opportunities, activities, tasks, or custom objects, so Oleria doesn't populate resource-level Access Graph or Access Inventory data for Close. It also doesn't discover connected email and calendar accounts, or Send As delegations. ## Prerequisites * A Close user for Oleria whose role grants **Manage Groups, Users, Billing & Roles/Permissions** (`manage_organization`), such as Close's built-in **Admin** role. A dedicated integration user is best. See [Permissions for reading](#permissions-for-reading) for what Oleria reads without it. * An API key created by that user. See [Create the Oleria credential in Close](#create-the-oleria-credential-in-close). * For groups and custom roles, the Close **Scale** plan or above. On other plans, Oleria discovers no groups. * Admin access on the Oleria platform to add a new integration. > [!NOTE] > > Use a dedicated Close user for Oleria rather than a person's account. A Close API key belongs to the user who created it, acts with that user's role, and never expires. If that user is deactivated or removed from the organization, the key stops working and syncs fail. > [!WARNING] > > Close API keys have no scopes, so there's no read-only key. The key can do anything its user's role allows, including changing users and roles. Oleria uses the same key for [remediation actions](#remediation-actions), so store it securely. ## Create the Oleria credential in Close **1. Choose the Close user** Pick the Close user Oleria will connect as, ideally a dedicated integration user. Give that user a role that grants **Manage Groups, Users, Billing & Roles/Permissions**, such as **Admin**. The tables below show what each permission is used for. **2. Create an API key** Sign in to Close as that user, go to **Settings** > **Developer** > **API Keys**, and create an API key. Copy the key. You enter it as **API key** when you connect. **3. Find the organization ID (only if needed)** If the user belongs to more than one Close organization, note the ID of the one to connect. It starts with `orga_` and is shown under **Settings** > **Organization**. If the user belongs to one organization, skip this step. ### Permissions for reading | Close permission | What Oleria reads with it | | :- | :- | | Any role | The organization, every user and their role, the role list, and groups and their members. Oleria's **Read users**, **Read groups**, and **Read roles** capabilities need only an active member's API key. | | **Manage Groups, Users, Billing & Roles/Permissions** (`manage_organization`) | Every webhook subscription. Without it, Close returns only the subscriptions the key's user created, with no error, so Oleria can't tell which ones are missing. It also gives access to the event log, for activity and last activity. | | `view_all_leads` | The event log, for activity and last activity, as an alternative to **Manage Groups, Users, Billing & Roles/Permissions**. Without either permission, Oleria shows no activity and no last activity. | ### Permissions for remediation actions Remediation actions are optional. Every action needs **Manage Groups, Users, Billing & Roles/Permissions** (`manage_organization`) on the key's user. Without it, Oleria refuses every action. | Action | Close requirement | | :- | :- | | Disable user accounts, Add user to role, Remove user from role | **Manage Groups, Users, Billing & Roles/Permissions** | | Enable user accounts, Create user | **Manage Groups, Users, Billing & Roles/Permissions**. Close also requires **Restrict new users to emails from these domains** to be on, and the user's email to be on one of your verified domains. | | Add user to group, Remove user from group, Create group | **Manage Groups, Users, Billing & Roles/Permissions**, and the Close **Scale** plan or above | | Disable NHI accounts | **Manage Groups, Users, Billing & Roles/Permissions** | ## Connect Close to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **Close**. **2. Complete the connection form** | Field | Notes | | :- | :- | | **API key** | Required. The key you created in Close. | | **Organization ID (optional)** | Required only when the key's user belongs to more than one Close organization. The ID starts with `orga_`. Leave it blank otherwise. You can't change this field later. | **3. Authenticate** Select **Authenticate**. Before it saves anything, Oleria checks the key with Close, finds the organization, and reads it. If the key's user lacks **Manage Groups, Users, Billing & Roles/Permissions**, Oleria still connects, but reads less, as described in [Permissions for reading](#permissions-for-reading), and refuses every remediation action. Find the newly connected organization on the **Connected** tab of your Oleria **Integrations** page, named **Close (*organization name*)**. If **Authenticate** fails, the message says what's wrong: * **Close rejected the API key (HTTP 401)** - the key is invalid or was deleted, or its user was removed from the organization. Create a new key and try again. * **Close denied access (HTTP 403)** - Close refused the key. Check that the key's user is an active member of the organization. * **The API key's user belongs to several organizations** - enter the **Organization ID** of the organization to connect. * **The API key's user is not a member of organization ...** - the **Organization ID** doesn't match any organization the key's user belongs to. Check the ID, or leave it blank if the user belongs to one organization. * **Close did not find the organization (HTTP 404)** - check the **Organization ID**. * **The API key's user belongs to no organization** - use a key created by a member of the organization you want to connect. * **Close could not be reached** - Close didn't respond. Try again in a few minutes. * **Connection validation failed (HTTP ...)** - Close returned an unexpected error. Try again. If it persists, contact [support@oleria.com](mailto:support@oleria.com). ### Edit the integration When you edit the integration, you can change **API key**. **Organization ID (optional)** can't be changed. To connect a different organization, add a new integration. * Leave **API key** blank to keep the stored key. * A new key must belong to the same Close organization. Otherwise, Oleria refuses it with **This API key belongs to Close organization ..., but the integration is connected to ...**. Select **Update** to save. Oleria runs the same checks as **Authenticate**. ## Verify the integration Confirm the organization appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, review the discovered users, roles, groups, NHIs, and activity in your Oleria workspace. In the integration's **Capabilities and operation readiness** section, **Read users**, **Read groups**, and **Read roles** show **Available**. If one shows **Needs permission**, Close refused the key. Check that the key's user is still an active member of the organization. If no groups appear, check that your Close plan includes groups. If webhook subscriptions are missing, check that the key's user has **Manage Groups, Users, Billing & Roles/Permissions**. If no activity or last activity appears, the key's user has neither that permission nor `view_all_leads`. ## Remediation actions Oleria can take these actions in Close: | Action | What it does | Revert | | :- | :- | :- | | Disable user accounts | Deactivates the user in the organization. Close keeps the user as a deactivated member. Oleria records the user's role. | Supported - adds the user back with the recorded role. Close doesn't let the API add a member with a role that grants **Manage Groups, Users, Billing & Roles/Permissions**, so for such a role Oleria adds the user as **User** and then changes the role. If Close refuses the change, Oleria gives the user **Super User** instead and says so in the result. If Close refuses that too, the revert fails with the user active as **User**, and the message says to set the role in Close. | | Enable user accounts | Adds a deactivated user back to the organization with their previous role, the same way as the **Disable user accounts** revert. This may add a billed seat. | Supported - deactivates the user again, if they still have the membership this action created. | | Create user | Adds a user with the email you provide to the organization, with Close's **User** role. Oleria uses only the email address. Close adds the user as active, even if the action asks for an inactive user. This may add a billed seat. | Supported - deactivates the user the action added. Close's API can't delete a user. | | Add user to role | Gives the user the role. A Close user holds exactly one role, so this replaces the user's current role. The user must be active. | Supported - restores the previous role. | | Remove user from role | Gives the user Close's **Restricted User** role. Close requires every user to hold one role, so Oleria replaces the removed role with the least-privileged one. The user must be active. If the user doesn't hold the role, Oleria makes no change. | Supported - restores the removed role. | | Add user to group | Adds the user to the group. The user must be active. | Supported - removes the user from the group. | | Remove user from group | Removes the user from the group. | Supported - adds the user back to the group. | | Create group | Creates a group with the name you provide. Oleria refuses a name that an existing group already uses, ignoring case. | Supported - deletes the group, but only while it has no members. | | Disable NHI accounts | For a webhook subscription, pauses it. The subscription isn't deleted: its URL, events, and signature key are kept. The integration's API key can't be disabled, because Close has no API to disable a key, and it's the key this integration connects with. | Supported - resumes the subscription, if it was active before the action and is still paused. | > [!NOTE] > > The **Remediations** page offers **Revert** only for **Disable user accounts**, **Remove user from group**, and **Disable NHI accounts**. The integration supports the other reverts in this table, but the Remediations page doesn't offer them yet. Oleria can revert only an action that completed or partially completed, never one that failed. Keep these limits in mind when you use these actions: * Oleria refuses to deactivate, or change the role of, the Close user who owns the integration's API key. It also refuses to deactivate the organization's last user with **Manage Groups, Users, Billing & Roles/Permissions**, or to give that user a role without it. * **Enable user accounts**, **Create user**, and the **Disable user accounts** revert add a member through Close's API. Close accepts this only when **Restrict new users to emails from these domains** is on and the email is on one of your verified domains. Otherwise, Close refuses, and the message says so. For a role that grants **Manage Groups, Users, Billing & Roles/Permissions**, see the **Disable user accounts** revert above. * **Create user** makes no change if an active user with that email already exists. If a deactivated user has that email, it fails. Use **Enable user accounts** for them instead. * **Remove user from role** can't remove **Restricted User**, because the user would have no role. * **Add user to role** works only with a role that exists in the organization. * Every action reads the current state first. If the user, group, or subscription is already in the state the action asks for, Oleria makes no change. After a change, Oleria reads it back from Close, and the action fails if the change isn't there. * Oleria sends **Create user** and **Create group** only once. If Close doesn't answer, Oleria checks for the new user or group. If it now exists, the action succeeds. * Reverting an action changes only what the action changed. If the target changed since the action, for example the user's role changed again or the group gained members, the revert makes no change and says why. * Group actions need the Close **Scale** plan or above. On other plans, Close refuses them and the action fails. ## Known limitations * **No SSO or security settings.** Close's API doesn't report your single sign-on (SSO) configuration or enforcement, whether 2FA is enforced for the organization, trusted email domains, or Close Support Access. Users show SSO as unavailable, and MFA reflects only each user's own 2FA enrollment. * **No login history.** Close's API has no login history, last login, or last password change. Oleria's last activity is the user's newest event-log entry, which is their last data change. Users who only read data, and deactivated users, show no last activity. * **30 days of activity.** Close keeps its event log for 30 days, so Oleria can't read older activity, and a user with no event in that time shows no last activity. Close's event log has no sign-in, role change, API key, or webhook events, so those changes don't appear as activity. Oleria doesn't import events about CRM records, saved searches, phone numbers, email templates, or sequences. Events from the last five minutes are read on the next sync. Close can still update an event for a few minutes after it happens, so each sync also reads the five minutes before its window again. * **Some actions aren't in Close's API.** Close's API can deactivate a user but not delete one, and can't end a user's sessions or reset their 2FA. Oleria doesn't offer **Delete user** or **Revoke sessions** for Close. Permissions belong to roles, so Oleria doesn't offer application or entitlement assignment. * **Other API keys and apps aren't listed.** Close's API lists neither other users' API keys nor the OAuth apps and integrations users have authorized. Oleria shows only its own API key. Another key appears only as a key ID on the events made with it. * **The API key can't be disabled.** Close has no API to disable an API key. To stop a key, delete it in Close, or deactivate its user. * **Webhooks need Manage Groups, Users, Billing & Roles/Permissions.** Without it, Oleria discovers only the webhook subscriptions the key's user created. * **Plan limits.** Groups and custom roles need the Close **Scale** plan or above. On other plans, Oleria discovers no groups, and group actions fail. * **No group owners or nesting.** Close groups have no owners, can't contain other groups, and don't hold roles. Roles can't be nested. ## 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.