Skip to main content
Connect Kustomer to Oleria to see who can work in your Kustomer organization, which permission sets and roles they hold, which teams and users can reach each queue and saved search, and which API keys, apps, and webhooks can act on your data. Oleria reads this data from the Kustomer API with an API key, so you can review privileged and non-human access and take action directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Kustomer organization:
  • Accounts - every user, with their name, email address, seat type (full-time, collaborator, or seasonal), status (active, deactivated, or invited), when they were created and updated, when they last changed their password, and when they last used Kustomer. Oleria also shows which sign-in methods your organization allows (password, Google, or SAML) and whether single sign-on is enforced.
  • Non-human identities - machine users, API keys, app tokens, installed apps, outbound webhooks, and inbound web, email, and form hooks. API keys and app tokens appear with the machine user they act as, their roles, their IP restriction, and when they were created, last used, and expire. API keys, app tokens, and webhook and hook secrets appear as credentials. Oleria never reads or stores key or secret values.
  • Roles - permission sets (built-in and custom), the Kustomer roles each permission set grants, the Kustomer roles held directly by users and machine users, and who holds each one.
  • Groups - teams, with their members and the permission sets each team grants.
  • Resources - routing queues, saved searches and the folders that contain them, and brands, with the user who created each saved search, folder, and brand as its owner.
  • Access - which teams are routed to each queue, and who can open each saved search: the user who created it, the users and teams it’s shared with, and, for searches shared with everyone, the All Kustomer users group.
  • Activity - the Kustomer audit log: sign-ins and sign-outs, and the user, team, permission set, role, password, saved search, and IP allow-list changes it records. Since Kustomer’s September 2026 release, the audit log records sign-ins and other activity but not configuration changes, which Kustomer shows in Change History instead.
Oleria refreshes this data on its regular sync schedule.
Oleria doesn’t import customers, conversations, messages, companies, or custom objects. The Kustomer audit log is available on the Enterprise and Ultimate plans. On other plans, Oleria syncs everything else and skips activity.

​
Prerequisites

  • A Kustomer administrator who can create API keys under Settings -> Security -> API Keys.
  • Your Kustomer organization name: the subdomain of your Kustomer address, for example acme for https://acme.kustomerapp.com.
  • Admin access to the Oleria workspace.

​
Create an API key

We recommend a dedicated API key for Oleria, so the Kustomer audit log clearly shows Oleria’s changes. Kustomer fixes a key’s roles when you create it, so choose all the roles now.
1

Open the API keys page

In Kustomer, go to Settings -> Security -> API Keys and select Add API Key.
2

Name the key and choose its roles

Enter a name such as Oleria and add the roles in the table below. Oleria needs the three required roles to connect. If the key lacks an optional role, Oleria skips that data, and the Capabilities tab doesn’t show it. The Capabilities tab shows whether Oleria can read users, teams, and permission sets, and which remediation actions the key allows.
3

Set the expiration and IP restriction

For Expires, choose an expiration that fits your key rotation policy. When the key expires, syncs stop until you update the integration with a new key. If you set a CIDR IP Restriction, include Oleria’s IP addresses. Contact support@oleria.com for the current list.
4

Copy the key

Save the key and copy the token. Kustomer shows it only once.
org.admin.security isn’t read-only. Kustomer also uses it for changing the organization’s sign-in settings and deleting API keys. Oleria only uses it to read, except when you run Revoke sessions or Disable non-human identity on an API key. Without it, Oleria can’t show API keys, app tokens, last activity, or sign-in settings.

​
Connect Kustomer to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Kustomer.
2

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Oleria checks that the key works and can read users, teams, and permission sets. Find the newly connected organization on the Connected tab of your Oleria Integrations page.
If Authenticate fails, Oleria shows the reason. Check that the organization name is correct, that the key hasn’t expired or been deleted, and that it has the three required roles. If Oleria reports that the subscription is inactive, your Kustomer organization needs billing attention in Kustomer before Oleria can connect.
You can connect each Kustomer organization to Oleria once. To keep the stored API key when you edit the integration, leave the API key field empty.

​
Verify the integration

Confirm the Kustomer organization 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, teams, permission sets, queues, and API keys in your Oleria workspace.

​
Remediation actions

These actions need the roles marked For actions in the table above. Revoke sessions also needs org.admin.security. Disable non-human identity needs org.admin.security, org.admin.user.write, and org.admin.user.read, even if you only deactivate machine users.
  • Disable account - deactivates the user, so they can no longer sign in. Reverting the action reactivates them.
  • Enable account - reactivates a deactivated user. Reverting the action deactivates them again.
  • Add to role and Remove from role - adds or removes a permission set or a Kustomer role on the user. Reverting the action undoes the change. If the user doesn’t hold the permission set or role directly but gets it through a team or another permission set, Remove from role fails and names the team or permission set to change instead.
  • Add to group and Remove from group - adds the user to a team or removes them from it. Reverting the action undoes the change.
  • Revoke sessions - signs the user out of every Kustomer session. This can’t be reverted.
  • Revoke permission - removes a user’s or team’s access to a saved search, or removes a team from a queue. For a saved search shared with everyone, it revokes access from All Kustomer users by making the search visible only to the users and teams it’s shared with. Reverting the action restores the access it removed.
  • Create user - creates a full-time user with the name and email address you provide, with the org.user role and any permission sets and teams you choose, and Kustomer emails them an invitation. Kustomer can’t create a user who is inactive, so unless the request activates the account, Oleria deactivates the new user right away and they can’t join until you run Enable account. Oleria never gives a new user the org.admin role. If a user with that email address already exists, the action makes no change and succeeds. Kustomer can’t delete users, so reverting the action deactivates the user, as long as nobody changed them since.
  • Create group - creates a team. If a team with that name already exists, the action makes no change and succeeds. Reverting the action deletes the team, as long as it still has no members.
  • Disable non-human identity - deactivates a machine user, or deletes an API key. Reverting the action reactivates the machine user. Kustomer can’t disable an API key, only delete it, so a deleted key can’t be restored.
Oleria confirms every change by reading it back from Kustomer, and keeps these limits:
  • Oleria won’t change or delete the API key it connects with, or the machine user that key acts as.
  • Oleria won’t add members to or remove members from the All Kustomer users group, because it isn’t a Kustomer team.
  • Oleria won’t revoke a saved search from the user who created it, because Kustomer always lets the creator open it. Delete or reassign the search in Kustomer instead.
  • If a user reaches a saved search only through a team or through All Kustomer users, revoking the user’s access fails and names the team or group to revoke instead.
  • A user can reach a queue only through a team. To remove a user’s access to a queue, remove them from the team, or remove the team from the queue.
  • Brands and saved search folders grant no access, so there’s no access to revoke.
  • Installed apps and their app tokens, and webhooks and hooks, can’t be disabled from Oleria. Kustomer can’t issue an app a new token, so deleting one would break the app for good. Uninstall the app, or disable the webhook in Kustomer instead.
  • If your organization uses Kustomer AI Agents, each AI Agent runs as a machine user. Before Disable account or Disable non-human identity deactivates a machine user, Oleria checks your AI Agents and won’t deactivate one that an AI Agent runs as, because the AI Agent would stop working. To pause an AI Agent, turn it off in Kustomer AI Agent Studio instead.
  • If Kustomer doesn’t let the API key read your AI Agents, Oleria can’t tell which machine users they run as. It then deactivates only a machine user that owns an API key, because an AI Agent’s machine user has none, and refuses the rest. Oleria needs org.admin.security to see the API keys.
  • If a user is already in the requested state, the action makes no change and succeeds. An API key that’s already deleted is reported as not found.

​
Known limitations

  • Kustomer doesn’t document multi-factor authentication for its own sign-in or report it through the API, so Oleria can’t show MFA status. If you use single sign-on and turn off password sign-in, your identity provider enforces MFA.
  • Sign-in methods are organization-wide in Kustomer, so every user shows the same methods.
  • Kustomer doesn’t provide a last sign-in time. Oleria uses the most recent activity on each user’s Kustomer sessions instead.
  • Teams can’t be nested in Kustomer.
  • The permissions on objects and attributes inside a permission set, the IP allow-list (Kustomer Access), and Technical Support Access aren’t available through the Kustomer API.
  • The Kustomer API doesn’t say who created an API key.
  • Kustomer applies one rate limit to every API key in your organization. Oleria paces its requests, but other integrations that use the Kustomer API may be slowed while Oleria syncs.
  • Kustomer returns at most 100 pages of any list. A list longer than that, such as more than 50,000 users, stops the sync instead of importing a partial list.
  • Kustomer lists at most 990 inbound web hooks (10 pages). If you have more, Oleria imports the first 990.
  • The audit log is available only on the Enterprise and Ultimate plans, and records successful sign-ins only. Sign-in and IP access monitoring is available only on the Ultimate plan.
  • Oleria reads the audit log only, not Change History, so configuration changes Kustomer records only in Change History don’t appear as activity.

​
Contact us

For questions about this integration, contact us at support@oleria.com.