Git providers (GitLab, Bitbucket)

FixControl delivers approved patches to four kinds of code host. GitHub has its own dedicated guide; this page covers GitLab and Bitbucket. The flow is the same for every host: you click Run fix on an issue, an agent produces a patch, the sandbox verifies it, and once the patch is approved a merge or pull request is opened on a new branch. Only the way you connect differs.

You need to be an admin of your FixControl organization to connect a code host. All connections live under Settings → Channels → Code & patch delivery.

GitLab

Sign in with GitLab (recommended for gitlab.com)

1. Open Settings → Channels → Code & patch delivery → GitLab and click Connect GitLab.
2. Choose Sign in with GitLab and click Continue with GitLab.
3. On GitLab, review the requested scopes (api and read_user) and approve.
4. You return to FixControl and the connection shows as connected.

Merge requests are attributed to your GitLab user, and tokens refresh automatically. The OAuth application belongs to FixControl; you don't register one yourself.

Personal access token (self-hosted GitLab, or as an alternative)

Use this path for a self-hosted GitLab instance, or when you prefer a token over signing in.

1. In GitLab, create a personal access token with the scope api.
2. In FixControl, open Connect GitLab and choose Advanced: paste a Personal Access Token.
3. For a self-hosted instance, fill in GitLab URL. Leave it blank for gitlab.com.
4. Paste the token and click Save token.

A token is tied to the user who created it. If that user leaves or the token expires, delivery stops until someone connects again.

What FixControl does when it delivers

• Creates a new branch named like fix/<issue-key>-<slug>-… from the codebase's branch.
• Commits the approved patch to that branch.
• Opens a merge request with a title and description taken from the issue.
• Never merges. Merging stays with your team.

Webhooks

GitLab has one webhook URL per project with a checkbox per event type, so FixControl uses one too: the CI/CD webhook you set up under Settings → DevOps. See DevOps & CI/CD for the exact URL, the events to enable and where the secret goes. Tick Merge request events and Pipeline events on that webhook; there is no second webhook to create.

What each event does:

Three properties of that path are worth knowing, because they are what makes a webhook trustworthy:

• It is verified, not trusted. The code-lane reading re-resolves the connection and re-verifies the signature over the same raw bytes the CI/CD lane verified. No "already checked" flag crosses between them.
• A redelivery is not a second effect. Each lane claims its own deduplication key, so GitLab re-sending a delivery is processed at most once per lane.
• A delivery is clamped to its own project, and state does not go backwards. An event cannot move a patch belonging to another project, and a late-arriving older event cannot undo a newer one.

The patch's delivery state is not the FixControl issue's state: merging the merge request does not close the issue. That stays a decision somebody makes.

If no webhook is set up, you can still refresh a merge request's state by clicking Check on the patch.

Bitbucket Cloud

Sign in with Bitbucket (recommended)

1. Open Settings → Channels → Code & patch delivery → Bitbucket and click Connect Bitbucket.
2. Choose Sign in with Bitbucket and click Continue with Bitbucket.
3. On Bitbucket, approve the requested access to repositories and pull requests.
4. You return to FixControl and the connection shows as connected.

The OAuth consumer belongs to FixControl; you don't create one yourself.

Access token or App Password

1. In Bitbucket, create a workspace or repository access token (recommended), or an App Password. Give it read and write access to repositories and pull requests.
2. In FixControl, open Connect Bitbucket and choose Advanced: paste an access token or App Password.
3. Paste the token. For an App Password, also fill in Bitbucket username; leave it blank for an access token.
4. Click Save token.

Pull request state

Merged and declined pull requests, and commit build status, can reach FixControl through a Bitbucket webhook. The webhook secret is managed by FixControl: ask your FixControl contact for the webhook URL and secret if you want this. Without a webhook, click Check on the patch to refresh a pull request's state.

Bitbucket Server / Data Center

FixControl can deliver patches to Bitbucket Server and Data Center, but there is no separate card for it under Settings → Channels today. Contact your FixControl contact to set it up. Have these ready:

• The base URL of your instance, for example https://bitbucket.internal.acme/. It must be reachable from FixControl.
• An HTTP access token with read access to the project and read and write access to the repositories.

Multiple providers in one organization

You can connect any combination of providers. For example: GitHub for product repositories, GitLab for an internal tools monorepo, Bitbucket for a legacy product. Each codebase points at exactly one provider, and agents use the right one automatically when a Run fix runs.

Common errors

FAQ

Can a single repository use multiple providers? No. Each codebase resolves to exactly one provider. If you mirror a repository across hosts, pick the canonical one and let the others sync from it outside FixControl.

Are tokens encrypted at rest? Yes. Every credential (OAuth tokens, refresh tokens, personal access tokens, App Passwords) is encrypted with AES-256-GCM before it is stored.

Can I replace a credential without losing in-flight patches? Yes. Connecting again replaces the stored credential. Patches already pushed are unaffected; new deliveries use the new credential.

Related: GitHub · Codebases · DevOps & CI/CD