Skip to main content

Gitlab authentication

This page documents the authentication and configuration options for the Gitlab agent connector.

Hosted mode (most cases)​

In hosted mode, create the connector through the Airbyte Agent CLI or API, then execute operations using the CLI, Python SDK, or API. If you need a step-by-step guide, see the developer quickstart.

OAuth​

Use the CLI for hosted OAuth connector creation when possible. It opens the hosted setup flow and avoids passing connector secrets through the command line:

airbyte-agent login
airbyte-agent connectors create --json '{
"workspace": "<your_workspace_name>",
"name": "gitlab"
}'

For API-first use cases, create a connector with OAuth credentials directly.

credentials fields you need:

Field NameTypeRequiredDescription
client_idstrYesThe API ID of the GitLab developer application.
client_secretstrYesThe API Secret of the GitLab developer application.
access_tokenstrYesAccess Token for making authenticated requests.
refresh_tokenstrYesThe key to refresh the expired access token.

replication_config fields you need:

Field NameTypeRequiredDescription
start_datestr (date-time)NoUTC date and time in the format YYYY-MM-DDTHH:mm:ssZ from which to start replicating data. If not set, all data will be replicated.

Example request:

curl -X POST "https://api.airbyte.ai/api/v1/integrations/connectors" \
-H "Authorization: Bearer <YOUR_BEARER_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"workspace_name": "<WORKSPACE_NAME>",
"connector_type": "Gitlab",
"name": "My Gitlab Connector",
"credentials": {
"client_id": "<The API ID of the GitLab developer application.>",
"client_secret": "<The API Secret of the GitLab developer application.>",
"access_token": "<Access Token for making authenticated requests.>",
"refresh_token": "<The key to refresh the expired access token.>"
},
"replication_config": {
"start_date": "<UTC date and time in the format YYYY-MM-DDTHH:mm:ssZ from which to start replicating data. If not set, all data will be replicated.>"
}
}'

Token​

Create a connector with Token credentials.

credentials fields you need:

Field NameTypeRequiredDescription
access_tokenstrYesLog into your GitLab account and generate a personal access token.

replication_config fields you need:

Field NameTypeRequiredDescription
start_datestr (date-time)NoUTC date and time in the format YYYY-MM-DDTHH:mm:ssZ from which to start replicating data. If not set, all data will be replicated.

Example request:

curl -X POST "https://api.airbyte.ai/api/v1/integrations/connectors" \
-H "Authorization: Bearer <YOUR_BEARER_TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"workspace_name": "<WORKSPACE_NAME>",
"connector_type": "Gitlab",
"name": "My Gitlab Connector",
"credentials": {
"access_token": "<Log into your GitLab account and generate a personal access token.>"
},
"replication_config": {
"start_date": "<UTC date and time in the format YYYY-MM-DDTHH:mm:ssZ from which to start replicating data. If not set, all data will be replicated.>"
}
}'

Execution​

After creating the connector, execute operations using the CLI, Python SDK, or API. If your Airbyte client can access multiple organizations, set the default organization with airbyte-agent organizations use, include organization_id in AirbyteAuthConfig, or include X-Organization-Id in raw API calls.

CLI

Authenticate with Airbyte:

airbyte-agent login

Create the connector. The CLI opens the hosted setup flow:

airbyte-agent connectors create --json '{
"workspace": "<your_workspace_name>",
"name": "gitlab"
}'

Describe the connector to see its supported entities and actions:

airbyte-agent connectors describe --json '{
"workspace": "<your_workspace_name>",
"name": "gitlab"
}'

Execute an action:

airbyte-agent connectors execute --json '{
"workspace": "<your_workspace_name>",
"name": "gitlab",
"entity": "<entity>",
"action": "<action>",
"params": {}
}'

Python SDK

The connect() factory returns a fully typed GitlabConnector and reads AIRBYTE_CLIENT_ID / AIRBYTE_CLIENT_SECRET from the environment:

The recommended pattern is build_connector_tools, which gives the agent three tools bound to this connector: inspect_connector, read_skill_docs, and execute. The agent can inspect the connector, read only the skill-doc section it needs, and then execute:

inspect_connector() -> read_skill_docs() -> read_skill_docs(section="...") -> execute(entity, action, params)

Pass section IDs verbatim as the outline lists them, prefix included (actions.<entity>.<action>, not <entity>.<action>); anything else returns an error the agent has to recover from.

The builder names its tools inspect_connector, read_skill_docs, and execute, so the tool sets for more than one connector collide when registered on the same agent. Renaming the callables at registration avoids the collision, but the generated execute guidance still names inspect_connector and read_skill_docs, pointing the model at the wrong tools. Use the agent_tool pattern below instead: it weaves your own names into that guidance.

Pydantic AI
from airbyte_agent_sdk import build_connector_tools
from pydantic_ai import Agent
from airbyte_agent_sdk import connect
from airbyte_agent_sdk.connectors.gitlab import GitlabConnector

connector = connect("gitlab", workspace_name="<your_workspace_name>")

tools = build_connector_tools(connector, framework="pydantic_ai")
agent = Agent("openai:gpt-4o", tools=tools.as_list())

Custom tool bodies​

When you need custom tool bodies — or a framework without native support — use GitlabConnector.agent_tool. Register execute, inspect, and docs together so the agent can fetch connector guidance progressively. Pass the framework explicitly when it has a supported failure strategy:

Pydantic AI
from pydantic_ai import Agent
from airbyte_agent_sdk import connect
from airbyte_agent_sdk.connectors.gitlab import GitlabConnector

connector = connect("gitlab", workspace_name="<your_workspace_name>")

agent = Agent("openai:gpt-4o")

@agent.tool_plain
@GitlabConnector.agent_tool(
framework="pydantic_ai",
inspect_tool="gitlab_inspect",
docs_tool="gitlab_read_docs",
)
async def gitlab_execute(entity: str, action: str, params: dict | None = None):
return await connector.execute(entity, action, params or {})

@agent.tool_plain
@GitlabConnector.agent_tool(framework="pydantic_ai")
async def gitlab_inspect():
return await connector.inspect_connector()

@agent.tool_plain
@GitlabConnector.agent_tool(framework="pydantic_ai")
async def gitlab_read_docs(section: str | None = None):
return await connector.read_skill_docs(section)

Use the same three-function pattern with framework="langchain", "openai_agents", or "mcp" and that framework's registration decorator. Each value translates connector failures into the framework's own signal:

framework=Tool failures surface as
"pydantic_ai"pydantic_ai.ModelRetry
"langchain"langchain_core.tools.ToolException (set handle_tool_error=True to feed it back to the model)
"openai_agents"the failure message returned to the model as the tool result
"mcp"fastmcp.exceptions.ToolError
"none" (default)airbyte_agent_sdk.AirbyteToolError

On a framework the SDK does not support natively — or in a raw LLM dispatch loop — omit framework= and handle AirbyteToolError yourself:

No framework
from airbyte_agent_sdk import AirbyteToolError
from airbyte_agent_sdk import connect
from airbyte_agent_sdk.connectors.gitlab import GitlabConnector

connector = connect("gitlab", workspace_name="<your_workspace_name>")

@GitlabConnector.agent_tool(
inspect_tool="gitlab_inspect",
docs_tool="gitlab_read_docs",
)
async def gitlab_execute(entity: str, action: str, params: dict | None = None):
return await connector.execute(entity, action, params or {})

@GitlabConnector.agent_tool()
async def gitlab_inspect():
return await connector.inspect_connector()

@GitlabConnector.agent_tool()
async def gitlab_read_docs(section: str | None = None):
return await connector.read_skill_docs(section)

# Advertise all three to the model, using each function's docstring as its description.
handlers = {
fn.__name__: fn
for fn in (gitlab_inspect, gitlab_read_docs, gitlab_execute)
}

# `tool_name` and `tool_args` come from the model's tool call in your dispatch loop.
try:
tool_result = await handlers[tool_name](**tool_args)
except AirbyteToolError as err:
tool_result = str(err) # hand the message back to the model as an errored tool result

Each function's docstring carries the guidance the model needs, so pass it through as the tool description wherever you register it.

Legacy alternatives​

These examples are kept for existing integrations. The deprecated GitlabConnector.tool_utils pattern loads the connector's full generated catalog into one broad execute tool description instead of letting the agent read skill docs on demand. For new code, use build_connector_tools or GitlabConnector.agent_tool above.

Pydantic AI
from pydantic_ai import Agent
from airbyte_agent_sdk import connect
from airbyte_agent_sdk.connectors.gitlab import GitlabConnector

connector = connect("gitlab", workspace_name="<your_workspace_name>")

agent = Agent("openai:gpt-4o")

@agent.tool_plain
@GitlabConnector.tool_utils
async def gitlab_execute(entity: str, action: str, params: dict | None = None):
return await connector.execute(entity, action, params or {})

Or pass credentials explicitly (equivalent, useful when you're not loading them from the environment):

Pydantic AI
from airbyte_agent_sdk import build_connector_tools
from pydantic_ai import Agent
from airbyte_agent_sdk.connectors.gitlab import GitlabConnector
from airbyte_agent_sdk.types import AirbyteAuthConfig

connector = GitlabConnector(
auth_config=AirbyteAuthConfig(
workspace_name="<your_workspace_name>",
organization_id="<your_organization_id>", # Optional for multi-org clients
airbyte_client_id="<your-client-id>",
airbyte_client_secret="<your-client-secret>"
)
)

tools = build_connector_tools(connector, framework="pydantic_ai")
agent = Agent("openai:gpt-4o", tools=tools.as_list())

API

curl -X POST 'https://api.airbyte.ai/api/v1/integrations/connectors/<connector_id>/execute' \
-H 'Authorization: Bearer <YOUR_BEARER_TOKEN>' \
-H 'X-Organization-Id: <YOUR_ORGANIZATION_ID>' \
-H 'Content-Type: application/json' \
-d '{"entity": "<entity>", "action": "<action>", "params": {}}'

Open source mode​

In open source mode, provide API credentials directly to the connector.

OAuth​

credentials fields you need:

Field NameTypeRequiredDescription
client_idstrYesThe API ID of the GitLab developer application.
client_secretstrYesThe API Secret of the GitLab developer application.
access_tokenstrYesAccess Token for making authenticated requests.
refresh_tokenstrYesThe key to refresh the expired access token.

Example request:

from airbyte_agent_sdk.connectors.gitlab import GitlabConnector
from airbyte_agent_sdk.connectors.gitlab.models import GitlabOauth20AuthConfig

connector = GitlabConnector(
auth_config=GitlabOauth20AuthConfig(
client_id="<The API ID of the GitLab developer application.>",
client_secret="<The API Secret of the GitLab developer application.>",
access_token="<Access Token for making authenticated requests.>",
refresh_token="<The key to refresh the expired access token.>"
),
api_url="<GitLab instance hostname>"
)

Token​

credentials fields you need:

Field NameTypeRequiredDescription
access_tokenstrYesLog into your GitLab account and generate a personal access token.

Example request:

from airbyte_agent_sdk.connectors.gitlab import GitlabConnector
from airbyte_agent_sdk.connectors.gitlab.models import GitlabPersonalAccessTokenAuthConfig

connector = GitlabConnector(
auth_config=GitlabPersonalAccessTokenAuthConfig(
access_token="<Log into your GitLab account and generate a personal access token.>"
),
api_url="<GitLab instance hostname>"
)

Configuration​

The Gitlab connector also needs these configuration values to construct the base API URL.

  • Hosted CLI: airbyte-agent connectors create doesn't currently accept these configuration fields directly. For hosted connectors that need these values, create the connector with the hosted API replication_config, then use the CLI for describe and execute operations after creation.
  • Hosted API: pass these values in the connector creation replication_config.
  • Open source mode: provide these values with your local connector setup so the connector can build the correct API base URL.
VariableTypeRequiredDefaultDescription
api_urlstringYesgitlab.comGitLab instance hostname