Connections

Faros uses Connections for source authentication. You can set up these connections while adding a new source or through the Connections page. This page provides a centralized location to view and manage all your connections, including information on their last modification. Editing a connection automatically updates the authentication details for all sources linked to it. Deleting a connection, however, will cease data retrieval for any source using that connection. Additionally, you have the flexibility to create multiple connections for the same source, each with distinct permissions, allowing for tailored access control.

To set up a new connection, start by assigning a unique name and selecting the source type.

When you connect a specific source, you'll notice additional fields that may appear, as certain sources necessitate a particular set of permissions for Faros to successfully authenticate. To determine the required permissions, place your cursor over the help icon located next to the credential (e.g., API key or token) input field. For certain connections, Faros will verify the scope of your credentials. However, you have the option to bypass these verification checks by toggling Validate connection off.

Once your credentials are verified, for certain connections, you'll encounter additional prompts. For instance, with GitHub, you'll need to select or manually input the GitHub organizations you wish to sync data for.

Selecting GitHub organizations to sync

Selecting GitHub organizations to sync

Once you have created a connection, all future sources can use it to authenticate.

API token requirements

Faros uses API tokens to periodically pull metadata; define token expiration according to your company policy and automation.

SourceToken requirements
AsanaProvide a Personal Access Token. See the Asana documentation for instructions on creating the token.
Azure ReposProvide access token with the following permissions: Code (Read), Graph (Read).
BambooHRCreate an API key with a user that has an access level with 'View Only' permissions for the following fields on all employees: Basic Info -> First Name, Last Name; Address -> all fields; Contact -> Work Email; Hire Date; Job Information -> Job Title, Reporting to, Department
BitbucketVCS: Provide Bitbucket "App Password" with read permissions: Accounts: read, Pull Requests: read, Issues: read, Workspace membership: read, Projects: read, Repositories: read

CICD: Provide Bitbucket "App Password" with read permissions: Pipelines: read, Repositories, read
BuildkiteProvide Buildkite API access token with the following read permissions: Organization Access, Read Organizations, Read Pipelines, Read Builds, GraphQL API Access
ClickUpProvide a Personal API token. See the ClickUp documentation for instructions on creating the token.
CircleCIProvide a Personal API token. See the CircleCI documentation for instructions on creating the token.
CodeDeployProvide valid AWS credentials with the following permissions: codedeploy:ListDeployments, codedeploy:BatchGetDeployments
DatadogProvide an API token and Application key with scopes: user_access_read, incident_read
Docker RegistryProvide a docker token with the scope read_api
GitHubProvide GitHub classic API token with read permissions: repo, read:org, read:user. For fetching Copilot data the token should belong to an organization owner.

For fine-grained tokens there are Repository Permissions and Organization Permissions. For Repository Permissions, read-only: Metadata, Contents, Pull Requests. For Organization Permissions, read-only: Members, Administration (or GitHub Copilot Business if need only Copilot data). For fetching Copilot data the token should belong to an organization owner.

APIs used for Copilot data are Copilot Metrics (organization and team metrics) and Copilot User Management (seat assignments list). Copilot Metrics API requires GitHub admins to enable access to it first at Organization Settings -> Copilot -> Policies
GitHub EnterpriseProvide GitHub API token with read permissions: repo, read:packages, read:org, read:discussion, read:user, user:email, read:enterprise
GitLab, GitLab CE/EEProvide GitLab personal access token with read permissions: read_api
Jira Cloud, Jira Server/DCThe integration user needs application access to Jira, the 'Browse Users' global permission, and the 'Browse Project' and 'View Development Tools' permissions for each project
JenkinsProvide an API token. See the Jenkins documentation for instructions on creating the token
OpsgenieCreate an API key with "Read" and "Configuration access" rights. See the documentation
Octopus DeployProvide an Octopus Deploy API token. Octopus does not have permission scopes on their API tokens.
OktaProvide an Okta token with scopes okta.users.read and okta.groups.read
PagerDutyCreate a read-only API key by navigating to https://<your-org>.pagerduty.com/api_keys (instructions)
PhabricatorCreate a Conduit API token with either a bot user or a regular user with visibility into the desired projects and repositories.
SentryProvide a Sentry token with scope org:read, project:read.
ServiceNowIntegration user should have the roles: sn_incident_read, cmdb_query_builder_read (details on roles)
SonarCloudCreate a user token with a user that has 'Browse' permissions for each project. See the documentation
SonarQubeCreate a user token with a user that has 'Browse' permissions for each project. See the documentation
other connectionsPlease reach out to [email protected] with questions.

Whatā€™s Next