CONNECT APP
Build with GitLab
Developer Tools
- OAuth
MCP
Give your agent GitLab tools
Every GitLab action is exposed as an MCP tool on Pipedream's remote server. Point a client at it with your end user's ID and Connect resolves that user's GitLab account for each tool call — you store no tokens.
// accessToken: mint a short-lived token with the Connect SDK — see the MCP guide
const transport = new StreamableHTTPClientTransport(
new URL("https://remote.mcp.pipedream.net/v3"),
{
requestInit: {
headers: {
Authorization: `Bearer ${accessToken}`,
"x-pd-project-id": "{project_id}",
"x-pd-environment": "production",
"x-pd-external-user-id": "{external_user_id}", // any stable ID for this user in your system
"x-pd-app-slug": "gitlab",
},
},
},
)
const mcp = new Client({ name: "my-agent", version: "1.0.0" })
await mcp.connect(transport)
const { tools } = await mcp.listTools()
// e.g. run Approve Merge Request:
const result = await mcp.callTool({
name: "gitlab-approve-merge-request",
arguments: {
projectId: "Project",
mergeRequestIid: 10,
},
})# access_token: mint a short-lived token with the Connect SDK — see the MCP guide
headers = {
"Authorization": f"Bearer {access_token}",
"x-pd-project-id": "{project_id}",
"x-pd-environment": "production",
"x-pd-external-user-id": "{external_user_id}", # any stable ID for this user in your system
"x-pd-app-slug": "gitlab",
}
async with streamablehttp_client("https://remote.mcp.pipedream.net/v3", headers=headers) as (read, write, _):
async with ClientSession(read, write) as session:
await session.initialize()
tools = await session.list_tools()
# e.g. run Approve Merge Request:
result = await session.call_tool("gitlab-approve-merge-request", {
"projectId": "Project",
"mergeRequestIid": 10,
})API PROXY
Call the GitLab API directly
For an endpoint with no pre-built tool, the Connect proxy forwards your request to the GitLab API with the connected user's credentials attached. You store no tokens and write no refresh logic.
const resp = await pd.proxy.get({
externalUserId: "{external_user_id}", // any stable ID for this user in your system
accountId: "apn_xxxxxxx",
url: "https://api.example.com/v1/me",
})
// Any allowed GitLab endpoint works here. Pipedream attaches the
// connected account's credentials to the outgoing request.# The path segment is the target URL, URL-safe base64 encoded:
# https://api.example.com/v1/me
curl "https://api.pipedream.com/v1/connect/{project_id}/proxy/aHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vdjEvbWU?external_user_id={external_user_id}&account_id=apn_xxxxxxx" \
-H "Authorization: Bearer {access_token}" \
-H "x-pd-environment: production"SDK
Run GitLab actions from your backend
Connect a user's GitLab account once, then run Approve Merge Request on their behalf from your own code — TypeScript, Python, or plain HTTP.
import { PipedreamClient } from "@pipedream/sdk"
const pd = new PipedreamClient({
projectId: process.env.PIPEDREAM_PROJECT_ID!,
clientId: process.env.PIPEDREAM_CLIENT_ID!,
clientSecret: process.env.PIPEDREAM_CLIENT_SECRET!,
projectEnvironment: "production",
})
const result = await pd.actions.run({
id: "gitlab-approve-merge-request",
externalUserId: "{external_user_id}", // any stable ID for this user in your system
configuredProps: {
gitlab: { authProvisionId: "apn_xxxxxxx" },
projectId: "Project",
mergeRequestIid: 10,
},
})from pipedream import Pipedream
pd = Pipedream(
client_id="{oauth_client_id}",
client_secret="{oauth_client_secret}",
project_id="{project_id}",
project_environment="production",
)
result = pd.actions.run(
id="gitlab-approve-merge-request",
external_user_id="{external_user_id}", # any stable ID for this user in your system
configured_props={
"gitlab": {"authProvisionId": "apn_xxxxxxx"},
"projectId": "Project",
"mergeRequestIid": 10,
},
)curl -X POST https://api.pipedream.com/v1/connect/{project_id}/actions/run \
-H "Content-Type: application/json" \
-H "X-PD-Environment: production" \
-H "Authorization: Bearer {access_token}" \
-d '{
"external_user_id": "{external_user_id}",
"id": "gitlab-approve-merge-request",
"configured_props": {
"gitlab": { "authProvisionId": "apn_xxxxxxx" },
"projectId": "Project",
"mergeRequestIid": 10
}
}'TOOLS
GitLab actions
On-demand operations your product or agent can configure and run on behalf of a connected user.
-
Approve Merge Request
actionApprove a merge request as the authenticated user, or withdraw an earlier approval by setting Action tounapprove. Call Get Merge Request first to check the merge request is actually ready — itsreadinessrollup reports the pipeline status, conflicts and how many approvals are still required — and Get Merge Request Diffs to read the changes being approved. Two things commonly go wrong: GitLab refuses to let you approve your own merge request, and a project may require approval from a specific approval rule that the authenticated user does not satisfy; both surface as a401. To approve as part of leaving review feedback in one step, use Create Merge Request Review with its Action set toapproveinstead. Optionally pass SHA to make the approval conditional on the merge request's head commit, so it fails rather than silently approving work that was pushed after you read the diff. See the documentationWritev0.0.1 -
Create Branch
actionCreate a new branch in the repository. See the documentationWritev0.3.4 -
Create Epic
actionCreates a new epic. See the documentationWritev0.0.6 -
Create issue
actionCreates a new issue. See the documentationWritev0.2.4 -
Create Merge Request
actionOpen a new merge request from one branch into another. Use this for "open an MR", "raise a merge request", "submit my branch for review". Both branches must already exist in the project — use List Repo Branches to check, or Create Branch to make one. Reviewers and assignees are given as usernames and resolved to IDs automatically; a username that is not a member of the project is rejected rather than silently dropped. Set Draft totruefor work that is not ready for review — GitLab expresses this by prefixing the title withDraft:, which this action does for you and which blocks merging until removed. After creating, use Get Merge Request to check its pipeline and merge readiness. See the documentationWritev0.0.1 -
Create Merge Request Comment
actionPost a comment on a merge request. It works in three modes, chosen by which props you set: leave File Path and Discussion ID blank for a plain comment on the merge request as a whole; set File Path plus a line number to open an inline thread anchored to that line of the diff; or set Discussion ID to reply inside an existing thread. Use Get Merge Request Diffs first to get valid file paths and line numbers, and List Merge Request Discussions to get a Discussion ID to reply to. Line numbers follow GitLab's diff rules: for a line the merge request adds or leaves unchanged, pass New Line; for a line it removes, pass Old Line; for an unchanged context line, pass both. Getting that wrong is the usual cause of a rejected inline comment. To post several review comments at once, and optionally approve in the same step, use Create Merge Request Review instead. See the documentationWritev0.0.1 -
Create Merge Request Review
actionSubmit a whole review on a merge request in one step: any number of inline comments anchored to lines of the diff, an overall summary comment, and optionally an approval. This is the tool for "review this MR" — call Get Merge Request and Get Merge Request Diffs first to read the changes, then send the findings back here. GitLab has no single submit-review API, so this action posts each inline comment as its own thread and then approves if asked; if an individual comment is rejected (usually a line that is not part of the diff) the rest are still posted and the failures are returned infailed, so check that array rather than assuming everything landed. Line numbers follow GitLab's diff rules:new_linefor a line the merge request adds,old_linefor a line it removes, both for an unchanged context line. There is no REST equivalent of GitLab's Request changes state — to block a merge request, leave the findings as comments and do not approve. See the documentationWritev0.0.1 -
Get Issue
actionGets a single issue from repository. See the documentationRead-onlyv0.2.4 -
Get Merge Request
actionGet a single merge request together with areadinessrollup that answers "can this be merged?" in one call — state, draft flag,detailed_merge_status, conflict flag, whether blocking threads are resolved, head pipeline status, and the approval count with who has approved. Use this to open or inspect a merge request, and before approving or merging one. It does not return the code changes: call Get Merge Request Diffs for those, and List Merge Request Discussions for existing review comments. If you only know the merge request by title, resolve itsiidwith Search Merge Requests first. The response also carriesdiff_refs, the commit SHAs needed to anchor inline comments — no other tool needs to fetch them. See the documentationRead-onlyv0.0.1 -
Get Merge Request Commits
actionList the commits contained in a merge request, newest first. Use this to understand how a change was built up — whether it is one clean commit or a long history to squash, who wrote each part, and what the commit messages claim. For the actual code changes call Get Merge Request Diffs instead; for merge readiness call Get Merge Request. See the documentationRead-onlyv0.0.1 -
Get Merge Request Diffs
actionList the file-level changes in a merge request — each changed file's path, whether it was added, deleted or renamed, and its unified diff. This is the tool to call before reviewing, approving or commenting on a merge request: thenew_pathvalues and the line numbers inside eachdiffhunk are what Create Merge Request Comment and Create Merge Request Review need to anchor an inline comment. Large merge requests can be trimmed with Paths (only files under the given prefixes) and Max Files. Watch fortoo_large: trueorcollapsed: trueon a file — GitLab omits or shortens those diffs, so do not conclude a file is unchanged. Use Get Merge Request for metadata and merge readiness, and Get Merge Request Commits for the commit history. See the documentationRead-onlyv0.0.1 -
Get Repo Branch
actionGet a single project repository branch. See the documentationRead-onlyv0.2.4 -
List Commits
actionList commits in a repository branch. See the documentationRead-onlyv0.0.5 -
List Group ID Options
actionRetrieves available options for the Group ID field.Read-onlyv0.0.2 -
List Group Path Options
actionRetrieves available options for the Group Path field.Read-onlyv0.0.2 -
List Groups
actionList all groups. See the documentationRead-onlyv0.0.2 -
List Merge Request Discussions
actionList the comment threads on a merge request — both general comments and inline threads anchored to lines of the diff. Use this to read existing review feedback before adding your own, to find what a reviewer objected to, or to get theidof a thread so you can reply to it with Create Merge Request Comment or close it with Resolve Merge Request Thread. Each thread's notes carryresolvable,resolvedand, for inline threads, theposition(file path and line) they are attached to. GitLab records label changes, assignments and other bookkeeping as system notes; those are filtered out by default because they are rarely what a reader wants — set Include System Notes totrueto see them. Set Only Unresolved totrueto get just the threads still needing attention. See the documentationRead-onlyv0.0.1 -
List Merge Requests
actionList merge requests, filtered by project, group, state, author, assignee, reviewer, labels or target branch. Use this for any "what merge requests are …" question — open MRs in a project, MRs waiting on my review (set Scope toreviews_for_me), MRs assigned to me, MRs targeting a release branch. Use Search Merge Requests instead when you have text to match against a title or description. Set Project to scope to one project, Group to scope to a whole group, or leave both blank to search across everything the authenticated user can see — note that with both blank GitLab defaults Scope tocreated_by_me, so passallto widen it. Results are summarized by default; set Detail tofullfor the complete merge request objects. The returnediidis what every other merge request tool needs. See the documentationRead-onlyv0.0.1 -
List Project ID Options
actionRetrieves available options for the Project ID field.Read-onlyv0.0.2 -
List Project Labels
actionList the labels defined in a project. Call this before applying labels with Create Merge Request: GitLab creates a label it does not recognize rather than rejecting it, so an invented or mis-cased name silently adds a new project label instead of applying the intended one. Each result'snameis the value to pass back; thedescriptionis worth reading because label names are often abbreviations. Narrow a long list with Search. See the documentationRead-onlyv0.0.1 -
List Project Members
actionList all members of a project. See the documentationRead-onlyv0.0.2 -
List Projects
actionList or search GitLab projects, optionally filtering by search term, membership, or ownership. Use this to discover projects (and their IDs) before acting on them with other GitLab actions. Supports ordering byname,path, creation/update time, star count, last activity, or searchsimilarity, plus pagination. Thesimilarityorder requires aSearchterm. See the documentationRead-onlyv0.0.3 -
List Repo Branches
actionGet a list of repository branches from a project. See the documentationRead-onlyv0.2.4 -
Resolve Merge Request Thread
actionMark a merge request thread as resolved, or reopen a resolved one by setting Resolved tofalse. Use this after acting on a piece of review feedback — resolving threads is what clears a merge request'sblocking_discussions_resolvedflag so it can merge. Get the Discussion ID from List Merge Request Discussions (set its Only Unresolved totrueto see just the threads still open). Only threads that are resolvable can be resolved: plain comments on the merge request as a whole are not, and GitLab rejects the attempt. See the documentationWritev0.0.1 -
Search Issues
actionSearch for issues in a repository with a query. See the documentationRead-onlyv0.0.5 -
Search Merge Requests
actionFind merge requests whose title or description matches a search term. Use this when the user refers to a merge request by what it is about ("the MR about the Redis cache refactor", "the payments migration MR") rather than by number - it is the fastest way to turn a description into theiidthat every other merge request tool needs. ALWAYS set Project (or Group) when you know which one the user means: a project-scoped search returns in well under a second, whereas an unscoped search scans every project the account can access and, on accounts that belong to many projects, can take tens of seconds and time out (HTTP 408). Leave both blank only when the project is genuinely unknown. Use List Merge Requests instead when there is no text to match and you only want to filter by state, author, reviewer or branch. Matching is case-insensitive substring, not fuzzy - prefer one or two distinctive words over a whole sentence. See the documentationRead-onlyv0.0.1 -
Update Epic
actionUpdates an epic. See the documentationWritev0.0.5 -
Update Issue
actionUpdates an existing project issue. See the documentationWritev0.0.4
-
New Commit (Instant)
triggerEmit new event when a new commit is pushed to a branchInstantv0.1.4 -
New Branch (Instant)
triggerEmit new event when a new branch is createdInstantv0.1.3 -
New Project
triggerEmit new event when a project (i.e. repository) is createdv0.1.4 -
New Audit Event (Instant)
triggerEmit new event when a new audit event is createdInstantv0.1.4 -
New Commit Comment (Instant)
triggerEmit new event when a commit receives a commentInstantv0.1.3 -
New Issue (Instant)
triggerEmit new event when an issue is created in a projectInstantv0.1.3 -
New Mention (Instant)
triggerEmit new event when you are @mentioned in a new commit, comment, issue or pull requestInstantv0.1.3 -
New Merge Request (Instant)
triggerEmit new event when a merge request is createdInstantv0.1.3 -
New Milestone
triggerEmit new event when a milestone is created in a projectv0.1.4 -
New Review Request (Instant)
triggerEmit new event when a reviewer is added to a merge requestInstantv0.1.3
MULTI-APP
Use GitLab with other popular apps
Most products don't stop at one integration. Pair GitLab with the other apps your users rely on, and ship use cases that span both.
- App slug
- gitlab
- Authentication
- OAuth
- Categories
- Developer Tools
- Actions
- 28
- Triggers
- 10
- API proxy
- Available
OAuth scopes
These are the scopes Pipedream's managed GitLab OAuth client requests when one of your users connects an account. Supply your own OAuth client to request a different set.
- api
- read_user
- read_repository
- write_repository
- read_registry
- sudo
- openid
- profile