GitLab

GitLab is a DevOps platform that combines Git repository management, CI/CD pipelines, issue tracking, and merge request workflows in a single application. The Nexla GitLab connector uses the GitLab REST API (v4) to ingest data such as projects, issues, merge requests, pipelines, commits, and users, and to write records back to GitLab by creating projects, issues, merge requests, and branches.

Power end-to-end data operations for your GitLab API with Nexla. Our bi-directional GitLab connector is purpose-built for GitLab, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to GitLab or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your GitLab workflows fast, secure, and fully governed.

Features

Type: API

SourceDestination

• Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
• Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
• API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
• Request optimization with intelligent batching, retry, and caching to minimize API calls and costs

Prerequisites

Before creating a GitLab credential, you need credentials that authorize access to the GitLab REST API. The connector authenticates by sending your token as a bearer token in the Authorization header of each request. GitLab supports two authentication methods for this connector: a personal access token (or project/group access token) used as an API key, or a registered OAuth 2.0 application.

Option 1 — Personal access token (API key)

A personal access token is the simplest way to authenticate REST API requests. To create one:

1. Sign in to your GitLab account and select your avatar in the upper-right corner, then choose Edit profile.

2. In the left sidebar, select Access tokens (under User settings / Access).

3. Click Add new token, then enter a token name and an optional expiration date.

4. Select the scopes your integration requires. Use api for full read and write access to the API, or read_api if the token only needs to read data.

5. Click Create personal access token, then copy the generated token value immediately, as it is shown only once.

For project- or group-scoped access, you can instead create a project access token or group access token from the project or group Settings > Access tokens page; these are used the same way.

Option 2 — OAuth 2.0 application

For an OAuth 2.0 authorization-code flow, register an application to obtain a client ID and client secret:

1. Sign in to GitLab, select your avatar, and choose Edit profile.

2. In the left sidebar, select Applications (the /-/user_settings/applications page).

3. Enter a name and redirect URI for the application, select the scopes it requires, and click Save application.

4. Copy the Application ID (client ID) and Secret (client secret). The client secret must be kept secure.

For GitLab.com, the authorization endpoint is https://gitlab.com/oauth/authorize and the token endpoint is https://gitlab.com/oauth/token. For a self-managed instance, substitute your instance domain. For complete details, see the GitLab REST API documentation, the personal access tokens guide, and the OAuth 2.0 guide.

Authenticate

Credentials required

Api Key

An authentication method that requires sending a unique secret token with each API request

Field	Required	Secret	Description
API Key Value	Yes	Yes	An encoded string value used as a secret token to authenticate API requests

OAuth 2.0

An OAuth authentication flow where users must authorize an application to access their data

Field	Required	Secret	Description
Authorization URL	No	No	The URL endpoint where users authenticate and authorize access
Client ID	Yes	Yes	A unique public identifier assigned to your application
Access Scope	No	No	A space-separated list of permissions your application requests
Token URL	No	No	The URL endpoint where authorization codes are exchanged for access tokens
Client Secret	No	Yes	A private key used to authenticate your application when requesting tokens

Create a credential in Nexla

1. After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.

2. Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.

3. Select the authentication method you want to use, and complete its fields:

   • For Api Key authentication, enter your GitLab personal access token (or project/group access token) in the API Key Value field. Nexla sends this value as a bearer token in the Authorization header of each API request.

   • For OAuth 2.0 authentication, enter the Client ID and Client Secret from your registered GitLab application, along with the Access Scope and, if you are connecting to a self-managed instance, the Authorization URL and Token URL for that instance. You will then be prompted to authorize Nexla's access to your GitLab account.

4. Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation.

Use as a data source

To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the GitLab connector tile, then select the credential that will be used to connect to GitLab, and click Next; or, create a new GitLab credential for use in this flow.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common GitLab endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below.

List all projects

Returns a list of projects visible to the authenticated user, with optional filters for visibility, ownership, and search term.

• This endpoint is paginated. Nexla automatically iterates through the available pages to fetch the full result set.

Retrieve a project

Returns detailed information for a single project identified by its ID or URL-encoded path.

• Provide the target project's ID in the endpoint parameters to identify which project to retrieve.

List all project issues

Returns a list of issues belonging to the specified project, with optional filters for state, labels, and milestone.

• This endpoint is paginated. Nexla automatically iterates through the available pages to fetch the full result set.

Retrieve a project issue

Returns a single project issue identified by its internal ID (iid).

• Provide the project ID and the issue's internal ID (iid) in the endpoint parameters to identify which issue to retrieve.

List all project merge requests

Returns a list of merge requests for the specified project, with optional filters for state, target branch, and labels.

• This endpoint is paginated. Nexla automatically iterates through the available pages to fetch the full result set.

Retrieve a merge request

Returns a single merge request identified by its internal ID (iid) within the specified project.

• Provide the project ID and the merge request's internal ID (iid) in the endpoint parameters to identify which merge request to retrieve.

List all project pipelines

Returns a list of CI/CD pipelines that have run for the specified project, with optional filters for status and ref.

• This endpoint is paginated. Nexla automatically iterates through the available pages to fetch the full result set.

Retrieve a pipeline

Returns detailed information for a single CI/CD pipeline run identified by its ID.

• Provide the project ID and the pipeline ID in the endpoint parameters to identify which pipeline to retrieve.

List all repository branches

Returns a list of branches in the project's repository, with an optional search filter.

• This endpoint is paginated. Nexla automatically iterates through the available pages to fetch the full result set.

List all repository commits

Returns a list of commits in the project's repository, with optional filters for ref, date range, and path.

• This endpoint is paginated. Nexla automatically iterates through the available pages to fetch the full result set.

Retrieve a commit

Returns detailed information for a single commit identified by its SHA.

• Provide the project ID and the commit SHA in the endpoint parameters to identify which commit to retrieve.

List all users

Returns a list of users on the GitLab instance, with optional filters for username, active status, and search term.

• This endpoint is paginated. Nexla automatically iterates through the available pages to fetch the full result set.

Retrieve a user as a regular user

Returns detailed information for a single user identified by their user ID.

• Provide the target user's ID in the endpoint parameters to identify which user to retrieve.

Retrieve current user details

Returns profile information for the currently authenticated user.

• This endpoint returns the profile of the user associated with the credential; no additional parameters are required.

Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.

Manual configuration

GitLab data sources can also be manually configured to ingest data from any valid GitLab REST API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request parameters. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.

Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new GitLab data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.

Use as a destination

Click the + icon on the Nexset that will be sent to the GitLab destination, and select the Send to Destination option from the menu. Select the GitLab connector from the list of available destination connectors, then select the credential that will be used to connect to GitLab, and click Next; or, create a new GitLab credential for use in this flow.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common GitLab endpoints. Select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

Create a project

Creates a new project owned by the authenticated user, with a required name and optional path, description, and visibility.

• Each record from your Nexset is sent as a request to create a project. Ensure each record includes a project name, which is required.

Create an issue

Creates a new issue in the specified project with a title and optional description, labels, and assignees.

• Each record from your Nexset is sent as a request to create an issue. Ensure each record includes the target project ID and an issue title.

Create a merge request

Creates a new merge request from a source branch into a target branch within the specified project.

• Each record from your Nexset is sent as a request to create a merge request. Ensure each record includes the target project ID, source branch, target branch, and title.

Create a repository branch

Creates a new branch in the project's repository from a given reference (branch, tag, or commit SHA).

• Each record from your Nexset is sent as a request to create a branch. Ensure each record includes the target project ID, the new branch name, and the reference to branch from.

Manual configuration

GitLab destinations can also be manually configured to send data to any valid GitLab REST API endpoint. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.

Save & activate

Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To send the data to the configured GitLab endpoint, open the destination resource menu, and select Activate.

The Nexset data will not be sent to the GitLab endpoint until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.