Skip to main content
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 (:<team uuid>) 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).
  • 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.

​
Prerequisites

  • A PactFlow tenant, either PactFlow Cloud (https://<tenant>.pactflow.io) or an On-Premises installation that Oleria can reach over HTTPS (see 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.
  • 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.
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, 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. 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, 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:
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://<tenant>.pactflow.io.
  • The two tokens belong to different accounts. Copy both tokens from the same user or system account.
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.
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. 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.
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.
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.