> ## 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. # Codacy > Connect Codacy to Oleria to discover your organization's members, Security Manager role, audit activity, and API tokens, and to remove people, change the Security Manager role, or delete repository API tokens from Oleria. Connect Codacy to Oleria to see who belongs to your Codacy organization, who holds the Security Manager role, and which API tokens can reach your repositories. Codacy is a code quality and security analysis platform. Oleria reads one Codacy organization at a time with an account API token, so you can review access to Codacy and take action directly from Oleria. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Codacy organization: * **Accounts** - every member of the organization, with their name, email addresses, Git provider username and ID, last Codacy login, the organization they belong to, and how they sign in. Codacy sign-in goes through your Git provider (GitHub, GitLab, or Bitbucket), so Oleria shows the sign-in method as that provider's login, not as MFA. The account that Oleria connects with also shows its Codacy creation date; Codacy doesn't report it for anyone else. All listed members are enabled, because a person who leaves the organization no longer appears. Oleria shows API access as available for every member, because any Codacy account can create an account API token. Only people who have signed in to Codacy and joined the organization appear: someone who has been invited but hasn't joined yet is not returned by Codacy. * **Roles** - three roles: **Member**, **Security Manager**, and **Organization Admin**. Every member holds **Member**. People whom Codacy lists as Security Managers (its organization manager role) also hold **Security Manager**, with the date the role was granted. **Organization Admin** is shown only for the account that Oleria connects with, because Codacy reports an administrator's role for that account alone. Every other organization admin appears as **Member**. Each role has a description of what it can do, taken from Codacy's roles and permissions page. * **Activity** - events from the Codacy organization audit log, such as Codacy sign-ins, account and repository API tokens created, listed, or deleted, people added to the organization or joining it, the organization manager role assigned or revoked, and changes to gate policies, coding standards, and organization or repository settings. Each event keeps its source (the Codacy app or the API), the role of the person who did it, and the repository it concerns with a link to it. Oleria keeps only a fixed set of safe event details, such as repository names, policy names, and permission levels, and drops everything else, because an event's details can include request data that Codacy doesn't mark as secret. Codacy keeps audit logs for one year, and the audit log is available only on the Codacy Business plan (see [Prerequisites](#prerequisites)). * **Non-human identities and credentials** - every credential Codacy lets Oleria see, each shown as a non-human identity with its credential: * **Repository API tokens** in your organization, and the **account API tokens**, **Git provider sign-in grants**, and **Enterprise provider token** of the account that Oleria connects with. The account's own credentials are linked to that account. * **Repository SSH keys** that Codacy stores to clone a repository. Oleria shows the public key's fingerprint only. * **Organization integrations**: the **Slack webhook**, the **Jira connection**, **webhook endpoints** (Codacy documents webhooks as a Business plan feature), and the names of the **auth headers stored for DAST targets**. Oleria skips any of these that Codacy denies the account the right to read, and the rest of the sync still completes. For each, Oleria shows a name, a description, where it lives (repository or organization), and its creation and expiry dates when Codacy reports them. A token is active until it expires, and a stored integration is shown as active while it is configured, because Codacy can't tell whether the other end still accepts it. Oleria never stores or shows a secret value: not a token, a Slack webhook URL, or the path or query of a webhook or DAST address. Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model). > [!NOTE] > > Oleria doesn't import repositories, so it doesn't populate Access Inventory or resource-level Access Graph data for Codacy. Codacy has no groups, so Oleria shows no groups either. This integration covers identity and access governance for members, roles, activity, API tokens, and other credentials. ## Prerequisites * A Codacy organization connected to GitHub, GitLab, or Bitbucket. Codacy Cloud and Codacy Self-hosted both work. * A Codacy **organization admin** account to create the account API token from. Codacy grants organization admin to people who are owners or admins of the organization on your Git provider (for example, a GitHub organization owner); you can't assign it in Codacy. If you use a dedicated service account, make it an owner or admin of the Git provider organization, sign in to Codacy with it, and join the organization before you create the token. **Authenticate** doesn't check the role, so a member-level token connects but every remediation action is refused. Oleria uses the token with that account's permissions, and the actions in [Remediation actions](#remediation-actions) require an organization admin. * The Codacy **Business plan**, if you want Oleria to import activity. Without it, Oleria skips the audit log and still syncs everything else. * Admin access to the Oleria workspace. > [!WARNING] > > A Codacy account API token has no scope of its own. It can do everything the account that created it can do, and Oleria uses the same token for [remediation actions](#remediation-actions). Store the token as an administrative credential. Codacy recommends creating the token from a dedicated service account, so the connection doesn't break when an employee leaves. Don't use Oleria to remove that account from the organization or to revoke its Security Manager role. ## Create an account API token in Codacy **1. Open your account settings** Sign in to Codacy as an organization admin, open your account, and go to the **Access management** tab. **2. Create the token** Under **Account API tokens**, select **Create API token**. Choose an expiration date of 7, 30, or 90 days, or a custom date up to one year from today. **3. Copy the token** Copy the token and store it securely until you've connected Oleria. When the token expires, Codacy rejects it, so [update the integration](#verify-the-integration) with a new token before then. **4. Find your provider code and organization name** Open your organization in Codacy. The address has the form `https://app.codacy.com///`. The first part is your Git provider code and the second is your organization name. | Code | Git provider | | :- | :- | | `gh` | GitHub Cloud | | `ghe` | GitHub Enterprise | | `gl` | GitLab Cloud | | `gle` | GitLab Enterprise | | `bb` | Bitbucket Cloud | | `bbe` | Bitbucket Server | ## Connect Codacy to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **Codacy**. **2. Complete the connection form** Select **Continue** and provide the following: | Field | Notes | | :- | :- | | Account API token | Required. The account API token you created in Codacy. | | Git provider code | Required. Select the code for your Git provider. The default is GitHub Cloud (`gh`). | | Organization name on the Git provider | Required. The organization name from your Codacy address. It can't contain `/`, `?`, `#`, or a backslash. One integration covers one organization. | | Codacy base URL | Optional. Leave empty for Codacy Cloud, which uses `https://api.codacy.com/api/v3`. For Codacy Self-hosted, enter `https:///api/v3`. The address must use `https` and can't contain credentials, a query, or a fragment. | **3. Confirm the connection** Select **Authenticate**. Oleria checks that Codacy accepts the token and that the organization exists. If **Authenticate** fails, Oleria shows the reason. The most common causes: * Codacy rejects the token (401). Check that it's a valid account API token that hasn't expired. * Codacy can't find the organization (404). Check the Git provider code and the organization name, and make sure the token's account belongs to that organization. > [!NOTE] > > You can connect each Codacy organization to Oleria once. To connect a different organization, add a new integration. ## Verify the integration Confirm the Codacy 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 accounts, roles, activity, and tokens in your Oleria workspace. > [!NOTE] > > If you rotate the token or it expires, update the integration in Oleria with the new token. To keep the stored token when you edit the integration, leave the **Account API token** field empty. The Git provider code and organization name are locked after you connect. If you clear **Codacy base URL**, Oleria uses Codacy Cloud. ## Required permissions The account that created the token determines what Oleria can read and do. The permissions below are role names from Codacy's own roles and permissions page. Codacy doesn't attach a permission to every endpoint Oleria uses, so some rows are inferred. | What Oleria does | Role the account needs | Source | | :- | :- | :- | | Read members and roles | Organization admin | Inferred. Codacy documents no permission for these endpoints, and the **People** settings page is available to admins only. | | Read the audit log | Organization admin, and the Business plan | Codacy's permission table lists audit logs as admin only. Codacy's API reference also allows organization managers, so treat admin as the safe requirement. | | Read repository API tokens | Repository admin on each repository, or organization admin | Codacy's permission table: "manage repository API tokens". Oleria skips a repository where Codacy denies the token list. If Codacy denies it for every repository, Oleria still imports the account tokens and the organization-level credentials, and says in its log that repository API tokens are missing. | | Remove a person, assign or revoke the Security Manager role | Organization admin | Codacy's permission table. Oleria checks this before it runs an action. | | Read the Slack, Jira, webhook, and DAST credentials | Organization admin or manager | Inferred. Codacy documents no permission for these reads; its permission table lets organization managers and admins manage webhook endpoints, and webhooks are on the Business plan. If Codacy denies a read (403), Oleria skips that source, logs it once, and still completes the rest. | | Read repository SSH keys | Repository admin on that repository, or organization admin | Inferred, because the key is a repository setting. Oleria skips a repository where Codacy denies it. | | Read the account's Git provider grants and Enterprise token | None beyond a valid account API token | Inferred. These belong to the connected account. The Enterprise token may be absent outside an Enterprise plan. | | Delete a repository API token | Organization admin, or repository admin on that repository | Codacy's permission table. Oleria checks this before it runs the action. The **Capabilities** tab shows the action as available only for an organization admin, because a repository admin's access depends on the repository. | > [!NOTE] > > Codacy doesn't document a reliable signal for a missing permission. If the token lacks a permission Oleria needs to read members or roles, the **Capabilities** tab may not show a **Needs permission** status for that row, and Oleria keeps the last saved capability until the read works again. ## Remediation actions Oleria can take these actions in Codacy. Each one uses the integration's account API token, and Oleria first checks that the token's account has the role the action needs. * **Remove a user from the organization**. The person loses access to the organization in Codacy, and Codacy stops analyzing their commits to private repositories. Oleria reads the member list first. If the person is already gone, the action succeeds without changing anything. Reverting the action adds the person back by email, and only if Oleria removed them. Codacy doesn't document whether a person who is added back returns as a member or as an invitation they must accept, so check the member list in Codacy after you revert. Reverting doesn't give back the Security Manager role: if the person held it, Oleria adds them back as a member and tells you the role was not restored, so assign it again after they rejoin. Removing someone from Codacy doesn't remove them from your Git provider organization. Depending on your Codacy organization's join settings, they may be able to join again on their own, so remove them from the Git provider organization as well. If the person hasn't accepted the invitation yet, the revert has nothing to remove: Codacy can't withdraw an invitation through its API, so Oleria leaves it in place and says so. Oleria refuses to remove or re-add the account that the integration connects with. Codacy also requires at least one organization admin to remain. * **Assign the Security Manager role**. Oleria gives a member the Security Manager role. Reverting the action revokes the role, unless someone has already removed it. Oleria refuses to change the role of the account that the integration connects with. * **Revoke the Security Manager role**. Oleria removes the role from a member. Reverting the action assigns the role again, unless the person already holds it. Oleria refuses to revoke the role of the account that the integration connects with. Codacy lists only people who were given the Security Manager role, so revoking it from someone who doesn't hold it, such as an organization admin or a plain member, succeeds without changing anything and is not reverted. If Codacy refuses the request, the action fails with a message saying so. * **Disable a non-human identity** for a repository API token. Oleria deletes the token in Codacy, so anything that uses it stops working. Deleting a token can't be reverted, because Codacy can't restore a deleted token. If the token is already gone from Codacy (for example, someone deleted it before Oleria's next sync), the action fails with "NHI not found" instead of succeeding, because a missing token looks the same as a wrong id. Oleria can't disable account API tokens: it only sees the tokens of the account it connects with, and deleting its own token would end the connection. > [!NOTE] > > Oleria can't change a person's repository roles, such as read, write, or admin. Codacy takes those roles from your Git provider. ## Known limitations * **No per-member roles.** Codacy's API doesn't return a role for each member. Oleria can't show a member's Git provider role, such as repository read, write, or admin, and it can show **Organization Admin** only for the account it connects with. Other organization admins appear as **Member**. * **Removing a person only removes them from Codacy.** They stay in your Git provider organization, and depending on your Codacy organization's join settings they may be able to join again on their own. Remove them from the Git provider organization as well. * **Reverting a removal doesn't restore the Security Manager role.** If the person held it, assign it again after they rejoin. * **Invited people aren't visible until they join.** Adding a person to your Codacy organization sends an invitation, and Codacy doesn't return them until they sign in and join. They appear in Oleria after that. * **Some profile details aren't available.** Codacy doesn't report when a password was last changed, the creation date of anyone but the connecting account, or whether MFA or single sign-on is required, so Oleria leaves those empty or shows them as unavailable. * **Security Manager list can be unavailable.** If Codacy denies the list of Security Managers, Oleria still imports every member and shows everyone with the **Member** role only, except the account that Oleria connects with, which still shows as **Organization Admin** if it is one. * **Members only.** Oleria imports people who signed up to Codacy and joined the organization. People who only author commits and aren't members aren't imported as accounts. * **No MFA or single sign-on data.** People sign in to Codacy through your Git provider, and Codacy's API doesn't show whether MFA or single sign-on is required. Oleria shows both as unavailable. * **Credentials: only one account's of each personal kind.** Codacy lets a token list only its own account's account API tokens, Git provider grants, and Enterprise token. Oleria can't list other people's. * **Some credentials can't be disabled.** Oleria can delete a repository API token. It doesn't disable SSH keys, the Slack webhook, the Jira connection, webhook endpoints, DAST auth headers, Git provider grants, or the Enterprise token, because removing those removes configuration in Codacy rather than disabling one credential. * **A short or failed credential read.** Codacy's webhook endpoint list has no paging, so if it returns fewer endpoints than the total Codacy reports, Oleria says so in its log and the missing endpoints aren't imported. If Codacy denies an optional credential source (HTTP 403) or reports it isn't configured (HTTP 404), Oleria skips it and the rest of the credentials sync completes. Any other error from one of those sources fails the credentials sync with a message that names the source, instead of showing no credentials. * **Some credential details aren't available.** Codacy doesn't return who created a credential or when it was last used (except a Git provider grant's last sign-in), and it doesn't say whether a stored Slack, Jira, or webhook secret is still valid at the other end. Whether a webhook endpoint has a signing secret isn't documented, so Oleria shows the endpoint's secret as a credential without reading it. * **One organization per connection.** Oleria doesn't traverse a Codacy Enterprise to find its organizations. Connect each organization separately. * **Activity needs the Business plan.** If Codacy denies the audit log, because your plan doesn't include it or the account isn't an organization admin, Oleria skips activity and the rest of the sync still completes. * **Rate limits.** Codacy Cloud allows 2,500 requests per 5 minutes per IP address and answers with HTTP 503 or 504 when it throttles requests. Oleria retries and paces its requests, so large organizations with many repositories can take longer to sync. Codacy Self-hosted isn't rate limited. * **Only partly verified against a live Codacy organization.** This integration was built from Codacy's published API documentation. It has been checked read-only against a test organization: members, roles, tokens, error messages, and the audit-log plan gate. It has not been verified live for removing and re-adding a member (including whether a re-added member returns as a member or as an invitation), assigning the Security Manager role to other members, deleting a repository API token, importing activity events, or the Slack, Jira, webhook, DAST, and SSH key credentials. ## 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.