FAQ

Use GitLab.com if your repos are on gitlab.com. Use GitHub.com if your repos are on github.com. Use GitLab Self-Hosted if you run your own GitLab instance. Each provider maps to a different setup flow - see the Provider Comparison page for a full breakdown.

Yes. One workspace can use GitHub.com, GitLab.com, and/or self-hosted GitLab at the same time. Connect each from Sources in the dashboard. Channel and user mappings are scoped per git source; routing pickers show grouped GitHub and GitLab lists.

Yes - for example separate teams, or one MergeMe workspace per Slack workspace you use.

Each MergeMe workspace connects to one Slack workspace. To post to a different Slack workspace, create a separate MergeMe workspace.

Go to Sources > Self-hosted in your workspace. Click Yes, use self-hosted GitLab (owners and admins only) - MergeMe generates your HTTPS webhook URL and tokens. Paste them into a group or project webhook in GitLab, then add channel mappings under Routing > Channel mappings. New workspaces do not get self-hosted credentials until you opt in.

In GitLab, go to Settings > Webhooks, find your webhook, and click Test. GitLab will show you the response code from MergeMe. A 200 means it's working. Other common issues:

• Your GitLab instance can't reach https://api.mergeme.dev on port 443 - check firewall / outbound HTTPS rules
• The signing or secret token doesn't match what's under Sources > Self-hosted - regenerate and re-paste (enable self-hosted first if you have not yet)
• The wrong event types are enabled - enable Merge request events and Comments (or Note events on older GitLab)

The signing token (GitLab 19.0+) creates an HMAC-SHA256 signature over the request body with a timestamp, providing body integrity and replay protection. The secret token sends a plain value in a header with no integrity check. Use the signing token if your instance is on 19.0 or later.

GitLab 19.0 or later. Check your version at Admin Area > Dashboard or in the footer of your GitLab instance. If you're below 19.0, use the secret token field in GitLab instead.

For self-hosted GitLab, you choose one of two approaches (same MergeMe URL and tokens from Sources > Self-hosted): add one group webhook on each parent group that owns your projects (GitLab Premium or Ultimate; Settings > Webhooks), or add one webhook on each project individually. With a group webhook, map only the project IDs you need in MergeMe. GitLab.com and GitHub.com don't require manual webhooks - they're managed automatically.

No. Your GitLab instance must be able to make outbound HTTPS connections to https://api.mergeme.dev on port 443 so it can deliver webhook events to MergeMe. MergeMe never connects into your network - traffic is always initiated from GitLab.

MergeMe requests the api scope. This is the minimum scope that allows webhook management (creating and deleting project webhooks via the GitLab API). No narrower scope covers this operation.

Existing webhooks registered on your GitLab projects will remain but MergeMe will no longer be able to refresh its token. Incoming webhooks from GitLab will still be processed. To reconnect, go to Sources > GitLab.com and click Connect GitLab again.

Metadata: Read (required for all GitHub Apps), Pull requests: Read, and Issues: Read. The Issues permission is needed because GitHub delivers general PR body comments as issue_comment events. MergeMe does not request any write permissions.

Yes. During installation on GitHub, you can choose All repositories or Only select repositories. You can change this later in your GitHub org/account settings under Installed GitHub Apps.

GitHub sends an uninstall event to MergeMe, which clears the installation and removes your GitHub channel and user mappings. Slack notifications will stop for GitHub repos. To reconnect, go to Sources > GitHub and click Install GitHub App again, then reconfigure routing.

When MergeMe receives a webhook event, it looks at the author's username (GitLab or GitHub handle). If a mapping exists for that username, MergeMe @-mentions the corresponding Slack user in the notification. Without a mapping, the username appears as plain text.

The username appears as plain text in Slack (e.g. @johndoe without an actual Slack mention). No error occurs - the notification is still sent.

Slack notifies MergeMe, which revokes access and removes all channel and user mappings for this workspace. Notifications stop. To use Slack again, open the Slack tab, connect your workspace, then re-add channel and user mappings.

Per-repo label rules can send PRs/MRs to different Slack channels based on labels present when the card is first posted. Drag rules to set priority when multiple labels match. See Label routing for full details, including prevent-default posting and GitLab self-hosted.

Open Routing > Preferences for workspace-wide options such as excluded usernames and skipping draft PRs/MRs. See the Preferences guide.

MergeMe posts to Slack when a PR/MR transitions to: opened, in review, approved, changes requested, merged, or closed. There is one Slack message per PR/MR that gets updated in place as the PR/MR moves through these states. Comments are posted as thread replies on that message.

Yes - that's what channel mappings are for. Each project > channel mapping is independent. You can also add label routing rules to override the default channel when specific labels are present. See Routing.

Remove the channel mapping for that project under Routing > Channel mappings. For GitLab.com, MergeMe will also delete the webhook on the GitLab project. For self-hosted GitLab, remove the group or project webhook in GitLab manually if you no longer need it.