> ## 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. # PactFlow > Connect PactFlow to Oleria to discover your tenant's users, system accounts, teams, roles, applications, environments, API tokens, stored secrets, and audit activity, and to deactivate users, change team membership and roles, create teams, or disable system accounts from Oleria. Connect PactFlow to Oleria to see who can reach your PactFlow tenant, which teams and roles can reach each application and environment, and which system accounts and API tokens exist. PactFlow is SmartBear's contract testing platform, now also called Swagger Contract Testing. Oleria reads one PactFlow tenant at a time with the API tokens of one user or system account, so you can review access to PactFlow and take action directly from Oleria. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your PactFlow tenant: * **Accounts** - every user and system account in the tenant, with their name, email address, roles, creation and last update dates, and last activity. Last activity is the later of the last PactFlow sign-in and the last use of the account's API token. Deactivated users are included and shown as disabled. If PactFlow doesn't report whether a user is active, Oleria shows the user as disabled rather than guessing. Oleria marks an account as an admin when one of its roles grants `user:manage:*`, `role:manage:*`, `system_account:manage:*`, or `authentication_settings:manage`, so a custom role with admin rights is caught too. Oleria shows API access as available for every account except a person whose only role is **Viewer** or who holds no role. System accounts appear as machine accounts and as non-human identities of the service account type. * **Sign-in method** - for each person, Oleria shows SAML single sign-on, social login, or SmartBear ID email and password when PactFlow's sign-in details identify one, and shows the method as unavailable otherwise. A person who signs in with SAML is shown with single sign-on required. Oleria adds API token sign-in for anyone who has used an API token. MFA is shown as unavailable for people and as not applicable for system accounts. * **Teams** - every team, with its members and its team administrators. The **Default** team, which PactFlow adds every new user and application to, is shown as a built-in group. Oleria shows each team administrator as managing the team. * **Roles** - every role in the tenant, including predefined roles such as **Administrator**, **User**, **CI/CD**, **Team Administrator**, **Read-Only**, and **Viewer**, and any custom roles. Oleria shows which accounts hold each role. Each role has PactFlow's description, or a list of its permissions when PactFlow has no description. * **Applications and environments** - every PactFlow application (pacticipant) and deployment environment, with which teams and roles can reach each one: * A team reaches the applications and environments it owns, with the team-scoped (`:team`) permissions that its own members' and administrators' roles grant for that kind of resource. * A role with a tenant-wide (`:*`) permission, such as `contract_data:read:*`, reaches every application or environment that the permission covers. * A role with a permission scoped to one team (`:`) reaches that team's applications or environments. * **Activity** - events from the PactFlow audit trail, such as sign-ins and failed sign-ins, denied requests, token regenerations, role changes, team membership changes, stored secrets added or deleted, contract publications, contract downloads, and other changes. PactFlow doesn't document its event types, so Oleria classifies each event from the request it records. Each event keeps the person or token that did it, the IP address, and the request's method, path, status, and user agent. Oleria drops the request's query string, referrer, and remote host, because they can carry tokens or personal data. Oleria also drops events performed by the account that Oleria connects with, because PactFlow records every API read and Oleria's own reads would flood the log. The audit trail is available only on the PactFlow Enterprise plan (see [Prerequisites](#prerequisites)). * **Non-human identities and credentials** - every credential PactFlow lets Oleria see, each shown as a non-human identity with its credential: * The **read-only** and **read/write API tokens** of each system account, linked to that system account. * The **API tokens** of the account that Oleria connects with, linked to that account. * **Stored secrets** that webhooks use. When PactFlow assigns a secret to a team, Oleria records the team on the secret's details; the secret isn't linked to an account, because it doesn't sign anyone in to PactFlow. Each token is named after its owner with a `_ReadOnly` or `_ReadWrite` suffix and shows its description, expiry date, and when it was last used. A token is active until it expires, and is shown as disabled while the account that owns it is deactivated. A stored secret is shown as active while it is configured. Oleria never stores or shows a token or secret value. Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model). ## Prerequisites * A PactFlow tenant, either PactFlow Cloud (`https://.pactflow.io`) or an On-Premises installation that Oleria can reach over HTTPS (see [Known limitations](#known-limitations)). * A PactFlow user or system account for Oleria to connect as. A dedicated system account is recommended. The account needs these permissions: * On the Team and Starter plans, the **Administrator** role. Custom roles are available only on the Enterprise plan, so you can't give Oleria a read-only role on those plans. * On the Enterprise plan, you can instead use a custom role with the permissions in [Required permissions](#required-permissions). * The PactFlow **Enterprise plan**, if you want Oleria to import activity. Without it, Oleria skips the audit trail and still syncs everything else. * Admin access to the Oleria workspace. > [!WARNING] > > A PactFlow API token has no scope of its own. It carries the permissions of the account that owns it, and a read/write token can do everything that account can do. Oleria uses the read/write token for [remediation actions](#remediation-actions), so store it as an administrative credential. Use a dedicated system account, so the connection doesn't break when an employee leaves, and so you can tell Oleria's activity apart from people's. Oleria refuses to act on the account it connects with. ## Copy the API tokens from PactFlow PactFlow gives every user and system account one read-only API token and one read/write API token. You copy them from PactFlow; you don't create new ones. **1. Choose the account Oleria connects as** In PactFlow, choose the user or system account that Oleria will connect as. A dedicated system account is recommended. **2. Give the account the permissions Oleria needs** On the Team and Starter plans, give the account the **Administrator** role. On the Enterprise plan, you can instead give it a custom role with the permissions in [Required permissions](#required-permissions). Leave out the manage permissions for remediation actions if you only want Oleria to read. **3. Copy the read-only token** Go to **Settings** > **API Tokens**. A system account can't sign in: its tokens are listed on that page for an administrator with `system_account:read` or `system_account:manage`. A user's own tokens are visible only to that user, so sign in as them. Copy the read-only token. Oleria uses it to sync. **4. Copy the read/write token (optional)** To use [remediation actions](#remediation-actions), also copy the read/write token. It must belong to the same user or system account as the read-only token. Store both tokens securely until you've connected Oleria. ## Connect PactFlow to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **PactFlow**. **2. Complete the connection form** Select **Continue** and provide the following: | Field | Notes | | :- | :- | | Tenant URL | Required. Your PactFlow tenant URL, for example `https://.pactflow.io`, or your On-Premises host. If you leave out `https://`, Oleria adds it. The address must use `https` and can't contain credentials, a query, or a fragment. One integration covers one tenant. | | Read-only API token | Required. The read-only token you copied from PactFlow. | | Read/write API token | Optional. Needed only for remediation actions. The read/write token of the same user or system account as the read-only token. | **3. Confirm the connection** Select **Authenticate**. Oleria checks that PactFlow accepts each token and, when you enter both, that they belong to the same user or system account. If **Authenticate** fails, Oleria shows the reason. The most common causes: * PactFlow rejects a token (401). Check that it's a valid, unexpired API token for this tenant. * Oleria can't find the PactFlow API at the address (404). Check that you entered the tenant URL, for example `https://.pactflow.io`. * The two tokens belong to different accounts. Copy both tokens from the same user or system account. > [!NOTE] > > You can connect each PactFlow tenant to Oleria once. To connect a different tenant, add a new integration. ## Verify the integration Confirm the PactFlow tenant 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 accounts, teams, roles, applications, environments, activity, and credentials in your Oleria workspace. > [!NOTE] > > If you regenerate a token in PactFlow, update the integration in Oleria with the new token and select **Update**. To keep a stored token when you edit the integration, leave its field empty. The **Tenant URL** is locked after you connect. ## Required permissions The account that owns the tokens determines what Oleria can read and do. The permissions below are PactFlow's permission names, which you grant in a custom role on the Enterprise plan. On the Team and Starter plans, the **Administrator** role covers all of them. | What Oleria does | Permission the account needs | Notes | | :- | :- | :- | | Read users | `user:read:*`, `system_account:read:*` | `system_account:read:*` covers the system accounts in the same list. | | Read groups (teams) | `team:read:*` | | | Read roles | `role:read:*`, `user:read:*` | `user:read:*` covers who holds each role. | | Read applications and environments | `contract_data:read:*`, `environment:read:*` | Not shown on the **Capabilities** tab. | | Read system account API tokens | `system_account:manage:*` | If PactFlow denies the read, Oleria skips those tokens, says so in its log, and completes the rest of the sync. | | Read the connecting account's own API tokens | `token:manage:own` or `read_token:manage:own` | Skipped the same way if denied. | | Read stored secrets | `secret:manage:*`, or `secret:read:team` for the account's own teams only | Skipped the same way if denied. With `secret:read:team`, Oleria sees only the secrets of the account's teams. | | Read the audit trail | Inferred: **Administrator**, and the Enterprise plan | PactFlow documents no permission for the audit trail. If PactFlow denies it, Oleria skips activity and completes the rest of the sync. | | Deactivate or reactivate a user, assign or remove a role | `user:manage:*`, `system_account:manage:*` | For a single account, Oleria needs only the permission for its type: `user:manage:*` for a person, `system_account:manage:*` for a system account. | | Add or remove a user from a team | `team:manage:*` | For a single team, `team:manage:` also works, and so does `team:manage:team` when the account is an administrator of that team. The **Capabilities** tab shows the action as available only with `team:manage:*`. | | Create a team | `team:manage:*` | A team administrator's `team:manage:team` can't create teams. | | Disable a non-human identity | `system_account:manage:*` | | Every remediation action also needs the **Read/write API token**. Without it, Oleria refuses the action, because PactFlow refuses every change made with a read-only token. Oleria checks the account's permissions before it runs an action. > [!NOTE] > > PactFlow doesn't document a specific signal for a missing permission. When PactFlow denies a read of users, teams, or roles (HTTP 401 or 403), the **Capabilities** tab shows that row as not enabled. Any other error keeps the last saved capability until the read works again. ## Remediation actions Oleria can take these actions in PactFlow. Each one uses the integration's read/write API token, and Oleria first checks that the token's account has the permission the action needs. Oleria reads the current state before it makes a change. If the target is already in the requested state, the action succeeds without changing anything, and reverting it changes nothing either. Oleria refuses every action that targets the account it connects with. * **Deactivate a user**. Oleria sets a person or system account to inactive in PactFlow. Reverting the action reactivates them, unless they are already active. After the change, Oleria reads the account back to confirm it. On a tenant migrated to SmartBear API Hub, PactFlow accepts the change but ignores it, so the action fails with a message telling you to change the member's status in the SmartBear Admin Portal instead. Oleria refuses to deactivate a system account whose only roles are **SCIM** or **SwaggerHub**, because SmartBear manages those accounts for provisioning and the SwaggerHub integration. * **Reactivate a user**. Oleria sets an inactive person or system account to active. Reverting the action deactivates them again, unless they are already inactive. The same migrated-tenant check applies. * **Add a user to a team**. Oleria adds a person or system account to a team as a member. Reverting the action removes them, unless they've already left the team. * **Remove a user from a team**. Oleria removes a person or system account from a team. Reverting the action adds them back as a member, unless they've already rejoined. Oleria doesn't change team administrator status, so a team administrator stays an administrator of the team. If the person is only an administrator of the team and not a member, the action fails and tells you to change team administrators in PactFlow. You can remove people from the **Default** team. * **Assign a role**. Oleria gives a person or system account a role. Reverting the action removes the role, unless someone has already removed it. Oleria refuses the **Team Administrator** role, because PactFlow sets it per team and doesn't let it be assigned or removed directly. * **Remove a role**. Oleria removes a role from a person or system account. Reverting the action assigns the role again, unless the person already holds it. Oleria refuses the **Team Administrator** role for the same reason. If PactFlow refuses the change, for example because it would remove the last **Administrator**, the action fails with a message saying so. * **Create a team**. Oleria creates a team with the name you give and nothing else: no members, administrators, applications, or environments. If a team with the same name already exists (ignoring case), the action succeeds without creating anything, and reverting it deletes nothing. Reverting the action deletes only the team that Oleria created, and only while it's still unused. If the team now has members, administrators, applications, or environments, Oleria leaves it in place and tells you, so nobody loses access; delete it in PactFlow if that's intended. Oleria ignores its own connecting account when it checks, because PactFlow may add the creator to the new team. * **Disable a non-human identity** for a system account. Oleria sets the system account to inactive in PactFlow. Reverting the action reactivates it, unless it is already active. If the system account is no longer in PactFlow, the action fails with "NHI not found" instead of succeeding, because a missing account looks the same as a wrong id. Oleria refuses: * Anything that isn't a system account, such as a person. * A system account whose only roles are **SCIM** or **SwaggerHub**, because SmartBear manages it. * API tokens, because PactFlow can only regenerate a token, not revoke it. Disable the owning system account instead. * Stored secrets, because deleting one is irreversible and breaks the webhooks that use it. The same migrated-tenant check as **Deactivate a user** applies. > [!NOTE] > > Oleria doesn't delete or invite PactFlow users. Deleting a user can't be reverted, so use **Deactivate a user** instead. ## Known limitations * **No MFA data.** PactFlow doesn't store sign-in credentials. People sign in through SmartBear ID or your identity provider, and PactFlow's API doesn't show whether MFA is required. Oleria shows MFA as unavailable. * **No password change date.** Passwords live in SmartBear ID, so Oleria leaves the last password change date empty. * **Sign-in method values aren't documented.** PactFlow doesn't document the values that describe how someone signs in. Oleria shows the method as unavailable when it doesn't recognize them, never as a stronger method than it can confirm. People who sign in with SAML can also appear active after you disable them in your identity provider. * **Other people's API tokens aren't visible.** PactFlow has no API that lists another person's tokens. Oleria sees the tokens of system accounts and of the account it connects with. For everyone else, the last API use on the account is the only signal. * **Some credential details aren't available.** PactFlow doesn't return who created a system account or token, when a token was created, or when it was last regenerated. * **Activity needs the Enterprise plan and covers 30 days.** The audit trail is available only on the PactFlow Enterprise plan, and PactFlow keeps events for 30 days. Events older than that can't be imported. If PactFlow denies the audit trail, Oleria skips activity and the rest of the sync still completes. * **Least privilege needs the Enterprise plan.** Custom roles are Enterprise-only, so on the Team and Starter plans Oleria connects with the **Administrator** role, even if you only want it to read. * **Deactivation doesn't work on migrated tenants.** A tenant migrated to SmartBear API Hub ignores the active status that Oleria sets. **Deactivate a user**, **Reactivate a user**, and **Disable a non-human identity** fail on those tenants with a message pointing to the SmartBear Admin Portal. Oleria doesn't fall back to removing roles or teams. * **Team access can be over-reported for some members.** Oleria shows a team's access to its applications and environments with every team-scoped permission that the roles of the team's members and administrators grant for that kind of resource. A member whose own roles grant fewer team-scoped permissions has less access than the team edge shows. If none of their roles grants a team-scoped permission for a kind of resource, Oleria shows no team access to it. * **On-Premises hosts must be reachable.** Oleria is set up to reach PactFlow Cloud (`*.pactflow.io`). The **Tenant URL** must use HTTPS and can't point to a private or loopback address. Contact us before you connect an On-Premises host, so we can confirm Oleria can reach it. If Oleria can't reach the host, **Authenticate** fails with a message saying so. On-Premises installations haven't been tested. * **Editing can't remove the read/write token.** When you edit the integration, leaving **Read/write API token** empty keeps the stored token. To turn off remediation actions, remove the integration and connect it again with only the read-only token. * **Not yet verified against a live tenant.** This integration was built from PactFlow's published API documentation and not yet verified against a live tenant. In particular, sign-in methods, activity event types, the migrated-tenant behavior, and the remediation actions haven't been checked against real PactFlow responses. ## 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.