TigerGate supports four code providers out of the box. Pick the one your team uses — each has its own auth flow but the platform-side experience is identical.
ProviderAuth methodPR authorRecommended setup
GitHubGitHub App (installation token)TigerGate Bot (app identity)Install TigerGate GitHub App
Azure DevOpsPersonal Access Token (PAT)PAT owner’s identityUse a dedicated service account
GitLabPersonal / Project / Group Access TokenToken owner’s identityProject or Group token + service account
BitbucketApp PasswordPassword owner’s identityUse a dedicated service account

​
Why a service account?

When TigerGate creates automated remediation PRs (fixing vulnerabilities, applying SAST fixes), the PR author is determined by the credential used:
  • GitHub Apps — PRs show as authored by TigerGate[bot]. No extra setup.
  • PAT-based providers — PRs are attributed to the PAT owner. If you use your personal PAT, every fix PR will look like you opened it.
For everything except GitHub, strongly recommend creating a dedicated service account so the bot’s activity is clearly separated from real developers.

​
GitHub

GitHub connects only through the TigerGate GitHub App — the Connect GitHub button installs it, and there is no personal-access-token option in the dialog.
1

Open Integrations → Code Providers in the dashboard

Click Connect GitHub.
2

Install the TigerGate App on your org

GitHub redirects you to the App install page. Pick Only select repositories to scope, or All repositories for org-wide.
3

Authorize

GitHub redirects back to TigerGate. The app’s installation token is stored encrypted and rotates automatically.
PRs created by TigerGate show as authored by TigerGate[bot].

​
Required permissions

The GitHub App requests:
  • Contents — Read & Write (push fix branches)
  • Pull Requests — Read & Write (create PRs, leave inline comments)
  • Metadata — Read (list repositories)
  • Checks — Read & Write (post commit statuses for the quality gate)

​
Azure DevOps

1

Create a service account (recommended)

In Azure Active Directory, create a new user — e.g. [email protected]. Add to your Azure DevOps organisation. Grant Contribute + Create branch under Project Settings → Repositories → Security.
2

Generate a PAT as the service account

Sign in as the service account → User Settings → Personal Access Tokens → New Token.
FieldValue
NameTigerGate Automation
OrganisationPick yours
ExpirationUp to 1 year (rotate)
Code scopeRead & Write
Pull Request ThreadsRead & Write (for inline comments)
3

Connect in TigerGate

Dashboard → Integrations → Code Providers → Connect Azure DevOps.
  • Organisation — your Azure DevOps org name
  • Personal Access Token — paste the value from step 2
PRs show as created by TigerGate Bot (the service account’s display name).

​
PAT scope reference

ScopePermissionPurpose
CodeReadClone repos for scanning
CodeRead & WritePush fix branches for remediation PRs
Pull Request ThreadsRead & WriteCreate and comment on PRs
If you only grant Code: Read, scanning will work but automated remediation PRs will fail with a 401 error.

​
GitLab

Three token options, in order of preference:
OptionScopeWhen to use
Project Access TokenSingle projectJust one repo
Group Access TokenAll projects in a groupOrg-wide GitLab
Personal Access TokenWhatever your user can seeSolo / testing only
1

Create the token

Project → Settings → Access Tokens → Add a new token.
  • Role: Maintainer (needed for branch creation)
  • Scopes: api, read_repository, write_repository
2

Connect in TigerGate

Dashboard → Integrations → Code Providers → Connect GitLab. Paste the token.For a self-hosted / on-premise instance, tick “Self-hosted / On-premise GitLab” on the same GitLab card and enter your instance URL (e.g. https://gitlab.yourcompany.com) — there’s no separate provider card. SaaS GitLab (https://gitlab.com) needs nothing extra. On-premise connections are stored as the gitlab-onpremise provider.
Same flow as Project Access Token, but at Group → Settings → Access Tokens. Sub-projects inherit access automatically.

​
Bitbucket

1

Create a service account

Same recommendation as Azure DevOps — make a tigergate-bot user, invite to your Bitbucket workspace, grant Write access on the repos to scan.
2

Generate an App Password

Sign in as the service account → Personal settings → App passwords → Create app password.Permissions:
  • Repositories — Read, Write
  • Pull requests — Read, Write
3

Connect in TigerGate

Dashboard → Integrations → Code Providers → Connect Bitbucket.
  • Workspace — your Bitbucket workspace ID
  • Username — the service account
  • App password — the password from step 2
PRs show as created by the service account.

​
After connecting

Once connected, every repository the credential can see appears under Code Security → Repositories. You can:
  • Scans run automatically — the initial scan starts on connect (org setting Auto-scan all repositories on connect, on by default), and connected repos re-scan on push / PR webhooks (set up below)
  • Wire CI — head to CI/CD integration for the gating snippet
  • Enable AI code review on PRs — turn it on per repository in the repo’s Settings → In-House Scanning (see below)

​
AI code review on PRs

TigerGate can post inline review comments on the exact changed lines of a pull request, plus one-click AI fix suggestions. It is off by default: enable it per repository — open the repo’s Settings, and under In-House Scanning turn on In-House PR Review — and connect an AI provider under Integrations → AI Provider (reviews are skipped when no AI credential is configured). Once enabled, no CI wiring is required; the provider’s PR/MR webhook drives it. See AI Code Review for the full behavior and per-provider setup.

​
Provider webhooks (for auto-scan)

For push / PR events to auto-trigger scans, the provider has to POST to TigerGate when something happens. Most flows handle this for you, but the manual setup is here for reference and for auditors who need to know exactly what’s wired.

​
When the webhook is set up automatically

ProviderAuto webhook
GitHubAutomatic — the App handles it; nothing to do
GitLab (any token)Manual — configure via the dashboard’s Webhook Setup (see below)
BitbucketAutomatic on OAuth connect; manual for App Passwords (can’t manage repo webhooks)
Azure DevOpsManual — PATs can’t manage Service Hooks
When manual, every repo gets one webhook entry. TigerGate’s connect dialog shows the webhook URL + signing secret to paste in.

​
Webhook URL format

GitLab and Azure DevOps post straight to your region: 
POST https://<api-host>/api/git-webhooks/<provider>
     <api-host>  = the API host of the region your organization is in
     <provider>  = gitlab | azuredevops
You register these hooks yourself, per project or per organization, so the URL is chosen at that moment and nothing has to route it. The delivery goes directly to the region that owns the repository and crosses no other host. GitHub and Bitbucket use a shared receiver: 
POST https://hooks.tigergate.dev/r/<region>/<provider>
     <region>    = the code of the region your organization is in
     <provider>  = github | bitbucket
Neither of these URLs can be chosen per region — a GitHub App has one webhook URL for every installation, and Bitbucket’s hook is installed through a single OAuth consumer — so deliveries arrive with no region attached. The receiver reads which region owns the delivery, forwards it, and returns that region’s response unchanged; it stores nothing. See what leaves your region. Neither is something you normally type: GitHub’s is configured on the App and Bitbucket’s is installed automatically when you connect over OAuth.
Copy the URL from the connect dialog rather than typing it: Integrations → Code Providers → <provider> → Webhook Setup always shows the exact URL and signing secret for your org, with the right host for that provider. Pointing a hook at the wrong region sends your commits and diffs to a platform that rejects them.
There’s no per-provider ID in the path — TigerGate resolves the connection from the payload’s repository plus the signing secret. Each provider carries that secret its own way: GitHub’s Secret field (→ HMAC signature), GitLab’s Secret token (→ X-Gitlab-Token), Bitbucket via ?secret= in the URL, and Azure DevOps via the X-TigerGate-Webhook-Secret header — spelled out per provider below. The signing secret is generated when you connect the provider — it’s distinct per-provider so a leaked GitHub secret can’t replay GitLab events. Find the exact URL + secret under Integrations → Code Providers → <provider> → Webhook Setup. GitHub webhooks are configured at the App level and delivered automatically to every installation — there is no per-repo GitHub webhook to add.

​
GitLab

1

Open the project's webhooks page

Project → Settings → Webhooks → Add new webhook.
2

Fill the form

FieldValue
URLhttps://<api-host>/api/git-webhooks/gitlab — your region’s API host; copy it from Webhook Setup
Secret tokenthe signing secret from TigerGate
TriggersPush events + Merge request events
SSL verificationenabled
GitLab sends the Secret token back as the X-Gitlab-Token header on every delivery, and TigerGate enforces it — a missing or mismatched token is rejected. Paste the exact secret from the connect dialog.
3

Save + Test

GitLab’s Test → Push events button fires a sample payload — confirm GitLab reports a 200 response.
Self-hosted / on-premise GitLab works identically — same form, same X-Gitlab-Token enforcement; just swap the host for your TigerGate instance if you run TigerGate on-prem too. For org-wide setup use Group → Settings → Webhooks instead — the webhook fires for every project in the group, no per-repo wiring.

​
Bitbucket

Connecting via OAuth installs this webhook on every repo automatically (needs the webhook scope). These manual steps are only for App Password connections, or repos where the auto-install couldn’t run.
1

Open the repo's webhooks page

Repo → Repository settings → Webhooks → Add webhook.
2

Fill the form

FieldValue
TitleTigerGate
URLhttps://hooks.tigergate.dev/r/<region>/bitbucket?secret=<signing-secret> — copy it from Webhook Setup
TriggersRepository: Push + Pull request: Created, Updated, Merged
Bitbucket Cloud has no secret field, so the signing secret is embedded in the webhook URL as ?secret=<signing-secret> — copy the full URL (secret included) straight from TigerGate’s connect dialog. TigerGate enforces it on every delivery. Bitbucket Server / Data Center can instead send the secret as the X-TigerGate-Webhook-Secret header.
Bitbucket doesn’t expose a “test webhook” button — push a dummy commit (or open + close a PR) to verify.

​
Azure DevOps

1

Open the project's Service Hooks page

Project → Project settings → Service hooks → Create subscription.
2

Pick the trigger

Service: Web Hooks → Code pushed (one subscription) and Pull request created + Pull request updated (two more subscriptions).
3

Action settings

FieldValue
URLhttps://<api-host>/api/git-webhooks/azuredevops — your region’s API host; copy it from Webhook Setup
Resource details to sendAll
HTTP headersX-TigerGate-Webhook-Secret: <signing-secret>
4

Test → Save

The Test button fires a sample payload. Confirm Azure DevOps reports a successful (2xx) response before saving.
Azure DevOps doesn’t support a per-org webhook — you create the three subscriptions per-project. If a push doesn’t trigger a scan, the cause is usually a signature mismatch (the secret was rotated without updating the provider) or an event type that wasn’t enabled. Re-check the URL and secret against Integrations → Code Providers → <provider> → Webhook Setup.

​
Disabling auto-scan

If you only want manual / CI-driven scans, keep the connection but skip the webhook setup. Each repository’s Settings modal (opened from its detail page) also has an Enable In-House Scanning toggle under In-House Scanning — turn it off to skip webhook-triggered scans and reviews for that one repo.

​
Rotation

ProviderRotation cadenceHow
GitHub AppAutomatic — installation token rotates every hourNothing to do
Azure DevOps PAT90–365 days, depending on policyIssue new PAT, paste into the same dialog, save
GitLab token90–365 daysSame — replace in dashboard
Bitbucket App PasswordNo expiry, rotate manuallyReplace + revoke old
For PAT-based providers, the dashboard surfaces a warning under Integrations → Code Providers when a token is < 7 days from expiry. Set Notifications to ping Slack a week before so a stale credential never silently breaks scans.