# Code-hosting integrations Weblate integrates with code-hosting sites in several separate places: repository access, incoming notifications, and pushing translations back. The exact setup depends on whether you use Hosted Weblate or run your own Weblate instance, and on whether Weblate should push directly or create pull or merge requests. Use this page as a provider-oriented checklist. The individual setting pages remain the canonical reference for setting syntax. ## Setup overview 1. Grant Weblate access to the repository. * For GitHub repositories on Hosted Weblate, use the [Hosted Weblate app](https://github.com/apps/hosted-weblate) from Weblate’s Connect GitHub account flow. The App gives Hosted Weblate repository access without inviting the hosted weblate user. * For other Hosted Weblate repositories, and for direct SSH pushes outside the GitHub App workflow, add the hosted weblate user where it is available, see [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push). * For self-hosted Weblate, create a dedicated code-hosting user and grant access using Weblate’s SSH key or an HTTPS token, see [Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)](https://docs.weblate.org/hr/latest/vcs.md#vcs-repos-code-hosting). 2. Configure [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo) so Weblate can clone the repository. 3. Configure incoming notifications so Weblate pulls changes soon after a push. The repository webhook or app must point to the matching Weblate hook URL, and the project must have [Aktiviraj petlje](https://docs.weblate.org/hr/latest/admin/projects.md#project-enable-hooks) enabled. Component [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo) must match a repository URL from the webhook payload; see [Matching webhook targets](https://docs.weblate.org/hr/latest/admin/continuous.md#hooks-target-matching). 4. Decide how Weblate should push translations back: * Use [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) or [Mercurial](https://docs.weblate.org/hr/latest/vcs.md#vcs-mercurial) and [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) to push directly. * Use a provider-specific VCS backend, such as GitHub or GitLab, to create pull or merge requests. These backends need API credentials in the Weblate settings. 5. Optionally set [Prenesi granu](https://docs.weblate.org/hr/latest/admin/projects.md#component-push-branch) when Weblate should push to a branch in the upstream repository instead of using a fork where supported. ## Pushing changes from Weblate Each translation component can have a push URL set up (see [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push)), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit; this is enabled by default, see [Prenesi pri spremanju izmjene](https://docs.weblate.org/hr/latest/admin/projects.md#component-push-on-commit). If you do not want changes to be pushed automatically, you can push manually under Repository maintenance or using the API via [`wlc push`](https://docs.weblate.org/hr/latest/wlc.md#cmdoption-wlc-arg-push). In case you do not want direct pushes by Weblate, there is support for [GitHub zahtjevi za preuzimanje](#code-hosting-github-pull-requests), [GitLab zahtjevi za sjedinjavanje](#code-hosting-gitlab-merge-requests), [Gitea zahtjevi za preuzimanje](#code-hosting-gitea-pull-requests), [Pagure zahtjevi za sjedinjavanje](#code-hosting-pagure-merge-requests), [Azure DevOps zahtjevi za preuzimanje](#code-hosting-azure-devops-pull-requests), or [Gerrit review requests](#code-hosting-gerrit) reviews. You can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) in [Konfiguracija komponente](https://docs.weblate.org/hr/latest/admin/projects.md#component). Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center and Bitbucket Cloud: | Desired setup | [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) | [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) | [Prenesi granu](https://docs.weblate.org/hr/latest/admin/projects.md#component-push-branch) | |------------------------------------------------|----------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------| | No push | [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) | empty | empty | | Push directly | [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) | SSH URL | empty | | Prenesi na zasebnu granu | [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) | SSH URL | Branch name | | No push | [Mercurial](https://docs.weblate.org/hr/latest/vcs.md#vcs-mercurial) | empty | empty | | Push directly | [Mercurial](https://docs.weblate.org/hr/latest/vcs.md#vcs-mercurial) | SSH URL | empty | | GitHub pull request from fork | [GitHub zahtjevi za preuzimanje](#code-hosting-github-pull-requests) | empty | empty | | GitHub pull request from branch | [GitHub zahtjevi za preuzimanje](#code-hosting-github-pull-requests) | SSH URL [1](#empty) | Branch name | | GitLab merge request from fork | [GitLab zahtjevi za sjedinjavanje](#code-hosting-gitlab-merge-requests) | empty | empty | | GitLab merge request from branch | [GitLab zahtjevi za sjedinjavanje](#code-hosting-gitlab-merge-requests) | SSH URL [1](#empty) | Branch name | | Gitea merge request from fork | [Gitea zahtjevi za preuzimanje](#code-hosting-gitea-pull-requests) | empty | empty | | Gitea merge request from branch | [Gitea zahtjevi za preuzimanje](#code-hosting-gitea-pull-requests) | SSH URL [1](#empty) | Branch name | | Pagure merge request from fork | [Pagure zahtjevi za sjedinjavanje](#code-hosting-pagure-merge-requests) | empty | empty | | Pagure merge request from branch | [Pagure zahtjevi za sjedinjavanje](#code-hosting-pagure-merge-requests) | SSH URL [1](#empty) | Branch name | | Azure DevOps pull request from fork | [Azure DevOps zahtjevi za preuzimanje](#code-hosting-azure-devops-pull-requests) | empty | empty | | Azure DevOps pull request from branch | [Azure DevOps zahtjevi za preuzimanje](#code-hosting-azure-devops-pull-requests) | SSH URL [1](#empty) | Branch name | | Gerrit review | [Gerrit review requests](#code-hosting-gerrit) | SSH URL | Target branch name (optional) | | Bitbucket Data Center pull request from fork | [Bitbucket Data Center zahtjevi za preuzimanje](#code-hosting-bitbucket-data-center-pull-requests) | empty | empty | | Bitbucket Data Center pull request from branch | [Bitbucket Data Center zahtjevi za preuzimanje](#code-hosting-bitbucket-data-center-pull-requests) | SSH URL [1](#empty) | Branch name | | Bitbucket Cloud pull request from fork | [Bitbucket Cloud zahtjevi za preuzimanje](#code-hosting-bitbucket-cloud-pull-requests) | empty | empty | | Bitbucket Cloud pull request from branch | [Bitbucket Cloud zahtjevi za preuzimanje](#code-hosting-bitbucket-cloud-pull-requests) | SSH URL [1](#empty) | Branch name | * **[1]** Can be empty in case [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo) supports pushing. ## GitHub ### GitHub repository access #### Hosted Weblate GitHub App On Hosted Weblate, the recommended setup is to connect the [Hosted Weblate app](https://github.com/apps/hosted-weblate) from the Weblate workspace where your project lives. Use the Connect GitHub account flow, install the App on the GitHub user or organization that owns your repositories, grant it access to the repositories you want to translate, and import components from the connected GitHub account. The App-backed workflow uses GitHub installation access tokens for cloning, pushing translation branches, creating pull requests, and receiving incoming notifications. You do not need to invite the Hosted Weblate weblate GitHub user or configure a separate repository webhook for components imported this way. Use the Hosted Weblate weblate GitHub user only when you intentionally configure direct SSH pushes outside the GitHub App workflow, see [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push). #### HTTPS with personal access token For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo). Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials. To use this approach: 1. Create a personal access token as described in [Creating an access token for command-line use](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). 2. Include the token in your repository URL: `https://username:token@github.com/owner/repo.git`. This is suitable when you are starting with Weblate or working with a single repository. #### SSH with a dedicated user For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places. This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL. For GitHub, create a dedicated user, for example `weblate-bot`, and use GitHub SSH URLs for your repositories, for example `git@github.com:owner/repo.git`. On Hosted Weblate, use this SSH-user workflow only for direct SSH pushes outside the recommended [Hosted Weblate app](https://github.com/apps/hosted-weblate) workflow. #### NOTE When using GitHub for pull requests, the [Prenesi granu](https://docs.weblate.org/hr/latest/admin/projects.md#component-push-branch) configuration affects the behavior: if not set, the project is forked and changes are pushed through a fork. If set, changes are pushed to the upstream repository and the chosen branch. ### GitHub notifications Weblate comes with native support for GitHub. If you are using Hosted Weblate, use the [Hosted Weblate app](https://github.com/apps/hosted-weblate) from Weblate’s Connect GitHub account flow. It uses GitHub App webhooks, so you do not need to configure a separate Webhook in GitHub. Components imported from the connected GitHub account also use the App for repository access and pull requests, without inviting the Hosted Weblate weblate GitHub user. The [Hosted Weblate legacy app](https://github.com/apps/hosted-weblate-legacy) is kept for existing webhook-only setups. Its deliveries use the generic GitHub webhook URL and are authenticated using a separate webhook secret configured by the Hosted Weblate operator. Use it only when you need the legacy app to deliver GitHub notifications to Hosted Weblate. For self-hosted Weblate, register the GitHub App using the in-app registration flow described below. Weblate generates the App manifest, GitHub returns the credentials, and they are stored in the database - there is no settings-based configuration. #### Registering the GitHub App from Weblate The fastest way to add the GitHub App is to let Weblate generate a GitHub App manifest with the correct permissions, events, and webhook URL pre-filled: 1. Sign in to Weblate with an account that has management access. 2. Otvori Upravljaj → Veze za hosting koda → Registriraj Weblate GitHub aplikaciju. 3. Fill in the form. The GitHub host defaults to `github.com`; change it to your GitHub Enterprise hostname if needed. Leave Organization blank to register the App under your personal account, or enter an organization slug to register it under that org. 4. Click Continue to GitHub and confirm on GitHub’s Create GitHub App page (you can still rename the App there). 5. GitHub redirects back to Weblate, which exchanges the temporary code for the App ID, private key, webhook secret, and slug and stores them in the database. The Connect GitHub account button is available immediately afterwards. The manifest requests the permissions and event subscriptions Weblate needs (`Contents` and `Pull requests` read/write, `Metadata` read-only, `Organization administration` read-only, `Workflows` read/write, and the `Installation`, `Meta`, `Push` and `Repository` events), and sets the callback, setup and per-app webhook URLs automatically, so no manual GitHub App configuration is required. GitHub delivers the `Installation` and `Installation repositories` events to all GitHub Apps by default. GitHub only offers accounts where the signed-in GitHub user can install or request the app. If an organization is not shown during the install flow, check the user’s organization role and the organization’s GitHub App installation restrictions. On GitHub.com, public apps can be installed on other accounts; private apps can only be installed on the account that owns the app. #### Connecting a workspace Connected GitHub accounts are bound to a Weblate [workspace](https://docs.weblate.org/hr/latest/admin/workspaces.md#workspaces). A user with project administration rights for any project in a workspace can connect a GitHub account on that workspace. After connecting, every project in the workspace can import components from repositories the GitHub App installation has access to. For organization accounts, Weblate verifies that the install-time GitHub user can administer the organization installation. Projects that are not in a workspace cannot connect a GitHub account through the GitHub App. Removing a connected GitHub account also uninstalls the App from GitHub when no other Weblate workspace uses that installation. If another workspace still uses the installation, Weblate removes only the selected workspace connection. Components imported through that connection lose access to their repositories. Removing a workspace uninstalls its connected accounts the same way. Weblate removes the connection even when GitHub no longer knows about the installation, and keeps it only when GitHub could not be reached, so that the removal can be retried. Components imported through the GitHub App flow use the dedicated GitHub (via Weblate GitHub app) VCS backend. The component settings UI keeps the repository URL read-only to prevent the App-issued credentials from being redirected to an unrelated repository. #### Migrating existing components Weblate reports an informational diagnostic for Git and GitHub pull request components that can be migrated to a registered Weblate GitHub App. Follow the Migrate to GitHub App link from the diagnostic to review all eligible components in the workspace. Connect or update the GitHub account for the workspace, grant the App access to the listed repositories, and select the components to migrate. Weblate changes the selected components to the GitHub (via Weblate GitHub app) VCS backend, replaces their repository addresses with canonical HTTPS clone URLs, and removes separate push URLs because the App authenticates pushes to the source repository. #### App webhook URL Each registered Weblate GitHub App has its own webhook URL containing an opaque token that uniquely identifies a single registered App: ```text https://weblate.example.com/hooks/integrations// ``` Components using the GitHub (via Weblate GitHub app) VCS backend are matched only through this dedicated endpoint. All generic forge webhook endpoints exclude them from matching and response diagnostics, including `/hooks/github/`. Legacy GitHub App deliveries sent to the generic endpoint can match only components using a non-App VCS backend. When a repository is renamed or transferred on GitHub, the `Repository` event makes Weblate refresh the repositories of the connected GitHub account and point the affected components to the new repository URL. Apps registered before Weblate 2026.10.1 are not subscribed to this event; enable Repository under Subscribe to events in the App settings on GitHub. Refreshing repositories of a connected GitHub account retargets such components too, for example when the event was missed. Use [`refresh_github_repositories`](https://docs.weblate.org/hr/latest/admin/management.md#weblate-admin-refresh_github_repositories) to do this for all connected GitHub accounts at once. If you are not using a GitHub App, add the Weblate webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below: ![image](images/github-settings.png) The Payload URL consists of your Weblate URL appended by `/hooks/github/`, for example for the Hosted Weblate service, this is `https://hosted.weblate.org/hooks/github/`. You can leave other values at default settings. Weblate can handle both content types and consumes just the push event. #### SEE ALSO * [`POST /hooks/github/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-github-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### GitHub zahtjevi za preuzimanje This adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [GitHub API](https://docs.github.com/en/rest) to allow pushing translation changes as pull requests, instead of pushing directly to the repository. [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) pushes changes directly to a repository, while the GitHub backend creates pull requests. The latter is not needed for merely accessing Git repositories. To create pull requests, select GitHub as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) and configure [`GITHUB_CREDENTIALS`](https://docs.weblate.org/hr/latest/admin/config.md#std-setting-GITHUB_CREDENTIALS). For GitHub.com, use `api.github.com` as the API host. The token must allow Weblate to read and write repository contents and create pull requests. If Weblate should fork private repositories, the token might also need administration access. Use [Parametri za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs-params) to add labels or an assignee to pull requests. Weblate can also assign the GitHub account linked to the user who started the push. This dynamic assignee is only added to newly created pull requests, and is skipped when the push has no acting user or that user has no GitHub account linked to Weblate. GitHub ignores assignees without access to the repository, including the acting user, and Weblate reports them as a component alert. When Weblate pushes to an already open pull request, it adds only the configured labels and assignee that are missing. Applying labels and assignees requires permission to write pull requests; failures are reported as component alerts without failing a push which already succeeded. If creating a pull request fails with `404 Not Found`, GitHub can be refusing API access even when the repository is readable. Weblate checks the repository’s pull request creation policy and, for user tokens, the authenticated account. The failure alert reports confirmed findings and provides further checks when the cause remains unknown. Diagnostic lookup failures preserve the original pull request error. Check that the effective API token belongs to the intended fork owner and allows creating pull requests. For fine-grained tokens, check repository selection, resource owner, and Pull requests write permission. Also check organization restrictions and access to the source branch. For GitHub Apps, check installation access to the repositories and pull request permissions. A successful Git push does not verify API access: pushing can use a separate SSH key. The repository log includes GitHub’s request ID and permission headers when available to help investigate the failure. Accepted permission headers describe endpoint requirements, not the permissions granted to the token. ## GitLab ### GitLab repository access #### HTTPS with personal or project access token For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo). Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials. For GitLab, the token needs write_repository scope to be able to push changes to the repository. The project access token requires Developer role for pushing. The URL needs to contain a username. For a personal access token, it is the actual username: `https://user:personal_access_token@gitlab.com/example/example.git`. For project access tokens it can be a non-blank value: `https://example:project_access_token@gitlab.com/example/example.git`. #### NOTE The rules for using project access tokens have changed between GitLab releases, the non-blank value is the current requirement, but older versions had different expectations (project name, bot user name). Check GitLab documentation matching your version if unsure. #### SSH with a dedicated user For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places. This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL. For GitLab, create a dedicated user and use GitLab SSH URLs, for example `git@gitlab.com:group/project.git`. For Hosted Weblate repositories on GitLab, add the hosted weblate user with the required repository permissions, see [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push). ### GitLab notifications Weblate has support for GitLab hooks. Add a project webhook with destination to `/hooks/gitlab/` URL on your Weblate installation, for example `https://hosted.weblate.org/hooks/gitlab/`. #### SEE ALSO * [`POST /hooks/gitlab/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-gitlab-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### GitLab zahtjevi za sjedinjavanje This adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [GitLab API](https://docs.gitlab.com/api/) to allow pushing translation changes as merge requests instead of pushing directly to the repository. There is no need to use this to access Git repositories, ordinary [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) works the same, the only difference is how pushing to a repository is handled. With [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) changes are pushed directly to the repository, while the GitLab backend creates a merge request. To create merge requests, select GitLab as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) and configure [`GITLAB_CREDENTIALS`](https://docs.weblate.org/hr/latest/admin/config.md#std-setting-GITLAB_CREDENTIALS). The [Prenesi granu](https://docs.weblate.org/hr/latest/admin/projects.md#component-push-branch) configuration affects where Weblate pushes changes before opening the merge request. If it is not set, the project is forked and changes are pushed through a fork. If it is set, changes are pushed to the upstream repository and chosen branch. ## Gitea, Forgejo, and Codeberg ### Gitea, Forgejo, and Codeberg repository access #### HTTPS with an access token For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo). Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials. #### SSH with a dedicated user For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places. This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL. For Hosted Weblate repositories on Codeberg, add the hosted weblate user with the required repository permissions, see [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push). ### Gitea notifications Weblate has support for Gitea webhooks. Add a Gitea Webhook for Push events event with destination to `/hooks/gitea/` URL on your Weblate installation, for example `https://hosted.weblate.org/hooks/gitea/`. This can be done in Webhooks under repository Settings. #### SEE ALSO * [Webhooks in Gitea manual](https://docs.gitea.com/usage/repository/webhooks) * [`POST /hooks/gitea/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-gitea-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### Forgejo notifications Weblate has support for Forgejo webhooks. Add a Forgejo Webhook for Push events event with destination to `/hooks/forgejo/` URL on your Weblate installation, for example `https://hosted.weblate.org/hooks/forgejo/`. This can be done in Webhooks under repository Settings. #### SEE ALSO * [Webhooks in Forgejo documentation](https://forgejo.org/docs/latest/user/webhooks/) * [`POST /hooks/forgejo/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-forgejo-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### Gitea zahtjevi za preuzimanje #### Versionadded Added in version 4.12. This adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [Gitea API](https://docs.gitea.com/development/api-usage) to allow pushing translation changes as pull requests instead of pushing directly to the repository. There is no need to use this to access Git repositories, ordinary [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) works the same, the only difference is how pushing to a repository is handled. With [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) changes are pushed directly to the repository, while the Gitea backend creates pull requests. To create pull requests, select Gitea as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) and configure [`GITEA_CREDENTIALS`](https://docs.weblate.org/hr/latest/admin/config.md#std-setting-GITEA_CREDENTIALS). ## Bitbucket ### Bitbucket repository access #### HTTPS with an access token For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo). Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials. #### SSH with a dedicated user For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places. This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL. For Hosted Weblate repositories on Bitbucket, add the hosted weblate user with the required repository permissions, see [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push). To push directly, use [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) or [Mercurial](https://docs.weblate.org/hr/latest/vcs.md#vcs-mercurial) with [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push). ### Bitbucket obavijesti Weblate has support for Bitbucket webhooks. Add a webhook which triggers upon repository push, with destination to `/hooks/bitbucket/` URL on your Weblate installation, for example `https://hosted.weblate.org/hooks/bitbucket/`. ![image](images/bitbucket-settings.png) #### SEE ALSO * [`POST /hooks/bitbucket/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-bitbucket-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### Bitbucket Data Center zahtjevi za preuzimanje #### Versionadded Added in version 4.16. This adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [Bitbucket Data Center API](https://developer.atlassian.com/server/bitbucket/) to allow pushing translation changes as pull requests instead of pushing directly to the repository. #### WARNING This does not support Bitbucket Cloud API. There is no need to use this to access Git repositories, ordinary [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) works the same, the only difference is how pushing to a repository is handled. With [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) changes are pushed directly to the repository, while the Bitbucket Data Center backend creates a pull request. To create pull requests, select Bitbucket Data Center as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) and configure [`BITBUCKETSERVER_CREDENTIALS`](https://docs.weblate.org/hr/latest/admin/config.md#std-setting-BITBUCKETSERVER_CREDENTIALS). ### Bitbucket Cloud zahtjevi za preuzimanje #### Versionadded Added in version 5.8. This adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [Bitbucket Cloud API](https://developer.atlassian.com/cloud/bitbucket/) to allow pushing translation changes as pull requests instead of pushing directly to the repository. #### WARNING Ovo se razlikuje od Bitbucket Data Center API-ja. There is no need to use this to access Git repositories, ordinary [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) works the same, the only difference is how pushing to a repository is handled. With [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) changes are pushed directly to the repository, while the Bitbucket Cloud backend creates a pull request. To create pull requests, select Bitbucket Cloud as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) and configure [`BITBUCKETCLOUD_CREDENTIALS`](https://docs.weblate.org/hr/latest/admin/config.md#std-setting-BITBUCKETCLOUD_CREDENTIALS). ## Azure DevOps ### Azure Repos repository access #### HTTPS with an access token For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo). Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials. Use the HTTPS clone URL shown by Azure Repos for the repository. #### SSH with a dedicated user For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places. This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL. Use the SSH URL shown by Azure Repos for the repository. ### Azure Repos obavijesti Weblate has support for Azure Repos webhooks. Add a webhook for Code pushed event with destination to `/hooks/azure/` URL on your Weblate installation, for example `https://hosted.weblate.org/hooks/azure/`. This can be done in Service hooks under Project settings. #### SEE ALSO * [Web hooks in Azure DevOps manual](https://learn.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks?view=azure-devops) * [`POST /hooks/azure/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-azure-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### Azure DevOps zahtjevi za preuzimanje This adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [Azure DevOps API](https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-7.2) to allow pushing translation changes as pull requests, instead of pushing directly to the repository. [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) pushes changes directly to a repository, while the Azure DevOps backend creates pull requests. The latter is not needed for merely accessing Git repositories. To create pull requests, select Azure DevOps as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) and configure [`AZURE_DEVOPS_CREDENTIALS`](https://docs.weblate.org/hr/latest/admin/config.md#std-setting-AZURE_DEVOPS_CREDENTIALS). ## Pagure ### Pagure repository access #### HTTPS with an access token For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo). Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials. #### SSH with a dedicated user For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places. This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL. ### Pagure obavijesti Weblate has support for Pagure hooks. Add a webhook with destination to `/hooks/pagure/` URL on your Weblate installation, for example `https://hosted.weblate.org/hooks/pagure/`. This can be done in Activate Web-hooks under Project options: ![image](images/pagure-webhook.png) #### SEE ALSO * [`POST /hooks/pagure/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-pagure-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### Pagure zahtjevi za sjedinjavanje #### Versionadded Added in version 4.3.2. This adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [Pagure API](https://pagure.io/api/0/) to allow pushing translation changes as merge requests instead of pushing directly to the repository. There is no need to use this to access Git repositories, ordinary [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) works the same, the only difference is how pushing to a repository is handled. With [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) changes are pushed directly to the repository, while the Pagure backend creates a merge request. To create merge requests, select Pagure as [Sustav za kontrolu verzija](https://docs.weblate.org/hr/latest/admin/projects.md#component-vcs) and configure [`PAGURE_CREDENTIALS`](https://docs.weblate.org/hr/latest/admin/config.md#std-setting-PAGURE_CREDENTIALS). ## Drugi radni tokovi ### Gitee repository access #### HTTPS with an access token For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo). Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials. #### SSH with a dedicated user For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in [Repozitorij izvornog koda](https://docs.weblate.org/hr/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL repozitorija za prijenos](https://docs.weblate.org/hr/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Pushing changes from Weblate](#code-hosting-push-options). This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places. This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL. ### Gitee notifications Weblate has support for Gitee webhooks. Add a WebHook for Push event with destination to `/hooks/gitee/` URL on your Weblate installation, for example `https://hosted.weblate.org/hooks/gitee/`. This can be done in WebHooks under repository Management. #### SEE ALSO * [Webhooks in Gitee manual](https://help.gitee.com/webhook) * [`POST /hooks/gitee/`](https://docs.weblate.org/hr/latest/api.md#post--hooks-gitee-) * [Pristup repozitorijima iz Hosted Weblate](https://docs.weblate.org/hr/latest/vcs.md#hosted-push) ### Gerrit review requests Gerrit support adds a thin layer atop [Git](https://docs.weblate.org/hr/latest/vcs.md#vcs-git) using the [git-review](https://pypi.org/project/git-review/) tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository. The optional [Prenesi granu](https://docs.weblate.org/hr/latest/admin/projects.md#component-push-branch) setting selects the target branch for the Gerrit review. Leave it empty to use [Grana repozitorija](https://docs.weblate.org/hr/latest/admin/projects.md#component-branch). Use the short branch name, such as `main`; Weblate and `git-review` push the review to `refs/for/` automatically. Gerrit push options can be appended after `%` in either setting, for example `main%topic=l10n`. Gerrit interprets these options as the configured Weblate Gerrit account and applies its own permissions. The Gerrit documentation has the details on the configuration necessary to set up such repositories. There is no separate code-hosting credential setting for this backend. ### Docker credentials For Docker installations, code-hosting API credentials can also be provided through environment variables, see [Code-hosting sites credentials](https://docs.weblate.org/hr/latest/admin/install/docker.md#docker-vcs-config).