> ## 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. # Port > Connect your Port organization to Oleria to discover users, service accounts, teams, and roles, the credentials, webhooks, integrations, and secrets connected to your developer portal, and who changed them. Connect Port to Oleria to see who can reach your internal developer portal: users and service accounts, the teams and roles they hold, and the organization credentials, webhooks, integrations, and secrets that act on your Port organization. Oleria reads this data from the Port API with your organization credentials, so you can find dormant or over-privileged access and take action directly from Oleria. Each integration covers one Port organization. To bring in several organizations, add one integration for each. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Port organization: * **Organization** - your Port organization's name, region, and plan, and the sign-in methods its users have. When Port returns them, Oleria also shows organization settings such as whether Port support staff can access your organization. * **Accounts** - every user, whether active, invited, or disabled, with their name, email, status in your organization, roles, teams, whether they're an Admin, created and last-modified dates, and last login. Each user's license level (free or paid) comes from your Port plan. Oleria also shows how each user can sign in, such as password, Google, GitHub, or SSO, from the sign-in providers Port records, and whether the user is provisioned by SCIM. * **Roles** - Port's built-in **Admin**, **Admin Readonly**, and **Member** roles, one moderator role for each blueprint (for example `service-moderator`), any other role a user holds, and who holds each role. Each account also shows its highest role level: Admin, Admin Readonly, Moderator, or Member. * **Teams** - every team, its members, and its parent team, so nested teams show up as a hierarchy. Teams that Port syncs from your identity provider are marked as synced. * **AI agents** - if your organization uses Port AI agents and agent discovery is enabled for your Oleria workspace, Oleria discovers each agent with its title, description, status, execution mode (Automatic or Approval Required), the user who created it, and its owning team. An agent acts with the permissions of the user who runs it, so it has no account or credential of its own. Oleria never reads agent prompts. If AI agents aren't enabled for your Port organization, Oleria skips them without failing the sync. * **Non-human identities (NHIs):** | Non-human identity | NHI type | What Oleria shows | | :- | :- | :- | | Service account | `ServiceAccount` | Name, roles, status, created and last-modified dates, and last login. | | Organization credentials | `APIToken` | Name, Client ID, whether they're enabled, and created and last-modified dates. Organization credentials act as the organization's admin, so Oleria marks them as admin. The credentials Oleria connects with are marked, and their last activity is the latest sync. | | Webhook | `Application` | Title, identifier, description, type, whether it's enabled, whether request signature verification is on, created and last-modified dates, and the user who created it, shown as its owner. | | Integration | `ConnectedApplication` | Title, type, installation type, version, created and last-modified dates, and the user who created it, when Port records one. | | Organization secret | `Secret` | Name, description, whether it's editable, and created and last-modified dates. | Organization credentials, each webhook's ingestion key, and organization secrets also appear as credentials, with their dates and, where Port reports one, their status. Oleria never imports client secrets, secret values, webhook URLs or keys, or integration configurations. * **Activity** - Port's audit log: changes to blueprints, blueprint and action permissions, self-service actions and their runs, webhooks, integrations, secrets, and scorecards, and catalog entities changed in the Port UI, through the API, or through Port's MCP server, including user and team entities. Each event shows who made it - a user, a service account, organization credentials, or an integration - and whether it came from the Port UI or the API. A change to a user or team points to that account or team, and a change to an integration or secret points to that non-human identity when Port records which one changed. Other events point to your Port organization, with the blueprint, entity, or action recorded on the event. Failed events include Port's error message. Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model). ## Prerequisites * A Port organization in the EU (`app.port.io`) or US (`app.us.port.io`) region. * A Port user with the **Admin** role, to copy your organization credentials. * Admin access to the Oleria workspace. > [!WARNING] > > Organization credentials act as your organization's admin. Anyone who has the Client ID and Client Secret can read and change everything in your Port organization. Keep them somewhere safe until you enter them in Oleria. ## Permissions Port organization credentials have no scopes to choose. Port evaluates them as the organization's admin, so they hold every permission below. Oleria refuses personal credentials, whose Client ID is an email address, because Port evaluates them as that one user and they would sync an incomplete inventory. ### Required to sync | Data | Port permission | | :- | :- | | Users and service accounts | `read:users` | | Teams | `read:teams` | | Roles | `read:users`, `read:blueprints` | | Organization name, plan, and settings | Admin role (`role:Admin`) | | Organization credentials | `read:apps` | | Webhooks and integrations | `read:integrations` | | Organization secrets | `read:secrets` | | Team hierarchy (parent teams), matching activity to teams, and AI agents | `read:entities` | | Activity | `read:audit-log` | Users, teams, and roles are required. If Port refuses any of the other reads, the sync continues without that data. ### Required only for actions | Action | Port permission | | :- | :- | | Disable user accounts, Enable user accounts | `read:apps`, `read:users`, `role:Admin` | | Add user to group, Remove user from group | `read:apps`, `read:users`, `read:teams`, `update:teams` | | Add user to role, Remove user from role | `read:apps`, `read:users`, `read:blueprints`, `update:users` | | Create user | `read:apps`, `read:users`, `read:teams`, `create:users`, `delete:users` | | Create group | `read:apps`, `read:teams`, `create:teams`, `delete:teams` | | Disable non-human identity | `read:apps`, `read:users`, `read:integrations`, `update:integrations`, `role:Admin` | > [!NOTE] > > Organization credentials always include these permissions, so you can't leave them out. Oleria makes changes in Port only when an action is run from Oleria. ## Copy your organization credentials **1. Open Credentials in Port** Sign in to Port as an Admin. Select your profile picture at the bottom left, then select **Credentials**. ![Port profile menu open with Credentials highlighted](https://mintcdn.com/oleria/fupsbgnroBn4OP2m/images/integrations/port-io/step-1.png?fit=max\&auto=format\&n=fupsbgnroBn4OP2m\&q=85\&s=3c5c127a1b2561b42cd5d9666e844d99) **2. Copy the Client ID and Client Secret** Open the **Organization** tab and copy the **Client ID** and **Client Secret**. Don't use the **Personal** tab: personal credentials act as one user, and Oleria refuses them. ![Port Credentials dialog on the Organization tab with the Client ID and Client Secret](https://mintcdn.com/oleria/fupsbgnroBn4OP2m/images/integrations/port-io/step-2.png?fit=max\&auto=format\&n=fupsbgnroBn4OP2m\&q=85\&s=98914e1efce56aba17346f851849bfc8) **3. Note your region** Check the address you sign in to Port at: `app.port.io` is the EU region, and `app.us.port.io` is the US region. ## Connect Port to Oleria > [!NOTE] > > If you connected Port to Oleria with the earlier SCIM form (a SCIM base URL and token), the sync stops with an error asking you to reconnect. Remove that connection, then connect Port again with the Organization credentials and region below. **1. Open the integration** Go to your Oleria workspace, select **Integrations**, select the **Available** tab, and search for **Port**. **2. Complete the connection form** Fill in the connection form: | Field | Notes | | :- | :- | | Region | Required. **EU (app.port.io)** or **US (app.us.port.io)**, matching where you sign in to Port. Defaults to EU. | | Client ID | Required. The Client ID from the **Organization** tab. A Client ID that is an email address belongs to personal credentials and is refused. | | Client Secret | Required. The Client Secret from the same tab. Oleria stores it encrypted. | **3. Confirm the connection** Select **Authenticate**. Before it saves anything, Oleria checks that: * The Client ID isn't an email address. * Port accepts the Client ID and Client Secret in the region you chose. If Port rejects them, check the region and copy the organization credentials again. * The credentials can read your organization and its blueprints. If a check fails, Oleria shows which one and how to fix it. ## Verify the integration Confirm the integration appears on the **Connected** tab of your Oleria **Integrations** page as **Port (your organization name)**. After the first sync completes, check that users, service accounts, teams, roles, non-human identities, and activity appear in your Oleria workspace. > [!NOTE] > > When you edit the integration, you can change the **Region**, **Client ID**, and **Client Secret**. Leave **Client Secret** blank to keep the stored one. If you change the **Client ID**, enter its Client Secret too. The credentials must belong to the same Port organization: Oleria refuses credentials from another organization. To connect a different organization, add a new integration. ## Remediation actions Oleria can take these actions in Port. Each one runs with the organization credentials, and before every action Oleria checks that the credentials still act as the organization's admin. | Action | What it does | Revert | | :- | :- | :- | | Disable user accounts | Sets the user's status to **Disabled**. Port blocks a disabled user from signing in and from creating API tokens with their personal credentials. Tokens they already created stay valid until they expire, after up to 3 hours. | Supported - restores the user's previous status. Only an **Active** user can be disabled; an invited user is removed by deleting the invitation in Port. Port re-derives a user's roles when their status changes; Oleria puts back any role Port drops, so the user's access doesn't change. | | Enable user accounts | Sets a disabled user's status to **Active**, which restores sign-in and takes a seat again. Only disabled users can be enabled. | Supported - disables the user again. | | Add user to group | Adds the user to a team. | Supported - removes the user from the team. | | Remove user from group | Removes the user from a team. | Supported - adds the user back to the team. | | Add user to role | Gives the user a role: **Admin**, **Admin Readonly**, **Member**, or the moderator role of an existing blueprint. | Supported - removes the role again, and gives back any role Port removed when the action ran. | | Remove user from role | Removes a role from the user. A user's only role can't be removed. | Supported - gives the role back. | | Create user | Invites the email address to your organization as a **Member**, in the teams you choose, if any. Port sends the invitation email. The user appears as **Invited** and takes a seat once they accept. If a user with that email already exists, the action fails. | Supported - deletes the invited user while the invitation is still pending. If the person has already accepted, the account is left in place. | | Create group | Creates a team with the name you choose. If a team with that name already exists, the action fails. | Supported - deletes the team while it still has no members. If someone has added members, the team is left in place. | | Disable non-human identity | Disables a service account or a webhook. See [Disable non-human identity](#disable-non-human-identity). | Supported. | Keep these limits in mind when you use these actions: * **Oleria won't lock you out of Port.** It refuses to disable the organization's only active Admin, or to remove the **Admin** role from them. Service accounts don't count as active Admins. * **Teams synced from your identity provider can't be changed.** Port takes their members from your identity provider, so Oleria refuses to add or remove members. Change the membership in your identity provider. * **Users provisioned by SCIM.** If Port reports that a change conflicts with SCIM, the action fails. Make the change in your identity provider. * **Nothing to change.** If the user is already in the requested state - for example, already disabled, already in the team, or already holding the role - the action succeeds without changing anything. * **Changes are checked.** After each change, Oleria reads the user, team, or webhook again. If Port didn't apply the change, the action fails. * **Reverting doesn't undo later changes.** A revert changes only what the action changed: one team member, or one role. If a user, invited user, service account, or new team changed since, the revert leaves it as it is and reports a conflict. If the team member or role is already back where it was, or the target no longer exists, the revert succeeds without changing anything. * **Not available from Oleria.** Oleria can't delete users or teams, or revoke tokens a user already created. Deleting can't be undone, and Port has no API to revoke an issued token. Do these in Port. ### Disable non-human identity | Non-human identity | What disabling does | Revert | | :- | :- | :- | | Service account | Sets the service account's status to **Disabled**, so it can't create new API tokens. Tokens it already created stay valid until they expire, after up to 3 hours. | Supported - sets the service account back to **Active**. | | Webhook | Turns the webhook off. Port rejects events sent to it until it's turned on again. Its URL and key don't change. | Supported - turns the webhook back on. | If the service account or webhook is already disabled, the action succeeds without changing anything. If it no longer exists, the action fails. This action works only on service accounts and webhooks. To disable a person, use **Disable user accounts**. These non-human identities can't be disabled from Oleria: * **Integrations** - the Port API can't pause an integration, only delete it, which can't be undone. * **Organization credentials** - Port can only delete or rotate them. Neither can be undone, and both break every integration that uses the credentials. * **Organization secrets** - Port secrets have no disabled state. They can only be deleted, which can't be undone. ## Known limitations * **No MFA data.** The Port API returns no MFA enrollment or MFA policy, so Oleria can't show whether users have MFA. For users who can sign in only through SSO, Oleria shows MFA as handled by your identity provider. * **No SSO settings.** The Port API doesn't return your SSO connection or its settings. Oleria shows how each user signs in from the sign-in providers Port lists for them. SSO is available on Port's Standard and Enterprise plans, and SCIM on Enterprise. * **No sign-ins in activity.** Port's audit log doesn't record sign-ins, and Port shows its login logs only in its own UI. A user's last login comes from the last-login time Port records for your organization. * **User, team, and role changes appear as entity changes.** Port's audit log has no separate events for user, team, or role administration. These changes appear only as changes to the user's or team's catalog entity. * **90 days of activity.** Port keeps audit-log events for 90 days, so the first sync brings in at most the last 90 days. * **Catalog updates from integrations aren't imported.** Oleria imports catalog entity changes made in the Port UI, through the API, or through Port's MCP server, and leaves out the entity updates your Port integrations write as they sync data into Port. * **Events from unknown actors are skipped.** Oleria imports an event only when it can match who made it to a user, service account, organization credentials, or integration it discovered. For example, events by a user who has since been removed from Port are skipped. * **Webhook events point to the organization.** Port's audit events for webhooks don't say which webhook changed, so Oleria shows them on your Port organization, not on the webhook. * **No credential last-used dates.** Port doesn't record when organization credentials were last used. The credentials Oleria connects with show the latest sync time instead. * **Personal and service-account credentials aren't listed.** The Port API has no way to list personal credentials or a service account's Client ID and secret, so Oleria shows service accounts but not their credentials. * **Roles are built in.** Port has no custom roles, and roles can't be given to teams. * **Not imported.** Blueprints, catalog entities (except AI agents), self-service actions, pages, scorecards, and their permissions aren't imported, so Oleria doesn't show who can see or change them. Oleria reads blueprints only to list each blueprint's moderator role. Changes to these objects appear as activity on your Port organization. ## 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.