# Connect GitLab Repositories
Generated: 2026-11-02T06:32:36.708Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: integrations.gitlab
title: Connect GitLab Repositories
summary: Authorize GitLab.com access, review discovered repositories and bind a repository/ref to a Project.
kind: quickstart
product_area: data_integrations
status: stable
updated: 2026-10-31
canonical: /docs/integrations/gitlab
---
# Connect GitLab Repositories
## Prerequisites
Use a GitLab.com account with access to the repositories your Projects need. The connection remains bounded by the authorizing account's permissions.
## Authorize and discover
1. Open **Admin → Integrations → GitLab** and start **Connect GitLab**.
2. Sign in to the intended GitLab account and review its OAuth authorization screen.
3. Approve the intended access and return to Teammately.
4. Review discovered repositories. Use **Sync repositories** when account/repository access changes.
## Bind and verify
In Project **Reference Materials**, add the Git connection, choose the repository/ref and inspect indexing. Workspace authorization alone does not select a repository for the Project. Confirm the indexed content belongs to the intended repository and ref.
## Recover access
For missing repositories, check the connected account's GitLab membership and current repository permissions. Reconnect when authorization is revoked or the intended account changes; sync after correcting access. Keep provider authorization, discovery and Project indexing as separate diagnostic steps.
## Related reference pages
{% related-card-grid %}
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Workspace Integrations](/docs/admin-console/integrations)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
id: integrations.overview
title: Integrations
summary: Move Cases, source materials, external outputs, and benchmark results across Teammately's supported product boundaries.
kind: concept
product_area: data_integrations
status: stable
updated: 2026-10-30
canonical: /docs/integrations
---
# Integrations
## Definition
An integration connects customer-owned data or execution systems to a specific Teammately workflow. The useful boundary is not “send arbitrary records.” It is preserving enough identity, context, and version information for imported material to remain reviewable and for exported supporting information to remain interpretable.
## Choose the boundary
| need | Teammately boundary | preserve |
| --- | --- | --- |
| Bring behavior examples into a Project | Assets Cases or the Case import workflow | source identity, input, materials, attributes, current Project Input Schema |
| Give agents Project knowledge | Agent Setup → Reference Materials | source document identity, indexing state, intended use |
| Evaluate outputs produced elsewhere | Benchmark Evaluations → Import reference outputs | immutable Benchmark Version, exact Case IDs, output identity, measured telemetry |
| Send work to specialists | Expert Contributions and Expert UI | assignment, task context, Contribution state, Checkpoint, provenance |
| Use supporting information in another system | Run and Case result context | Run, Benchmark Version, Case version, Policy version, Rubric version, incomplete states |
Each pattern has a different lifecycle. Reference Materials are not Case materials. An external response is neither a Case-scoped reference output nor a Harness Version. A Contribution assignment is not a generic notification integration.
## Connection setup guides
| Need | Provider guides |
| --- | --- |
| Repository Reference Materials | [GitHub](/docs/integrations/github), [GitLab](/docs/integrations/gitlab), [Bitbucket Cloud](/docs/integrations/bitbucket) |
| Select tracing inputs for Cases | [Langfuse](/docs/integrations/langfuse), [LangSmith](/docs/integrations/langsmith) |
| Messaging | [Slack notifications](/docs/integrations/slack), [Microsoft Teams installation and tests](/docs/integrations/teams) |
| Training or inference access | [Provider credentials, identity and checks](/docs/integrations/training-and-inference) |
| Application/API automation | [Developer Guide](/docs/integrations/developer-tools), [SDKs](/docs/sdks), [CLI](/docs/cli), [REST](/docs/public-api) |
## Data movement principles
1. Read the owning product contract before transforming data. For Cases, start with Project Input Schema; for outputs, start with the immutable Benchmark Version.
2. Use backend-issued IDs as join keys and customer IDs as correlation keys.
3. Preserve versions when a downstream result depends on mutable source objects.
4. Distinguish acceptance from completion. Upload, artifact processing, evaluation, and expert work can have separate states.
5. Keep missing values missing. Do not turn unknown telemetry or incomplete evaluation into zero or false.
6. Reconcile a small sample before moving a full collection.
## Product UI and API boundaries
The product UI owns interactive setup, mapping, preview, conflict resolution, and human decisions. Automated integrations should use only a supported external contract that preserves the same object and version boundaries.
Internal browser endpoints, event payloads, database shapes, and service-to-service handlers are not customer integration contracts. Their presence in source code does not make them stable or safe to automate against.
{% example-demo title="External candidate evaluation" %}
A team produces assistant outputs in its own evaluation pipeline. It selects an immutable Benchmark Version, downloads the exact Case IDs, and maps one output to each Case. The imported output set becomes an output-only reference Run.
The team retains its own generation ID as correlation metadata while using the Teammately Run, Benchmark Version, and Case IDs as correctness-supporting information identity. Missing cost remains absent. The Run becomes interpretable after Rubric evaluation completes; successful upload alone is not a result.
{% /example-demo %}
## Private connectivity
Private connectivity is available as part of your Teammately deployment for data ingestion and model inference. [Ask us](https://teammately.ai/contact) about AWS PrivateLink, Azure Private Link, or equivalent connectivity for your environment.
Read [Admin Console](/docs/admin-console#private-connectivity) for the distinction between your network reaching Teammately and Teammately reaching your model endpoint.
## Fields, states, or lifecycle rules
- Projects scope reusable Cases, source materials, agent configuration, and correctness governance.
- Benchmark Versions freeze the Case and evaluator boundary used by a Run.
- API keys belong to organization administration and do not replace Project permissions.
- Imports and evaluations can be asynchronous.
- External outputs create non-Harness reference supporting information.
- Teammately supporting information informs customer review; it does not record a customer deployment decision.
## Related task pages
{% related-card-grid title="Integration workflows" %}
- [Import Case Examples](/docs/integrations/import-case-examples)
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Connect Model Outputs](/docs/integrations/connect-model-outputs)
- [Expert UI](/docs/integrations/reviewer-workspace)
- [Check candidate correctness](/docs/integrations/check-candidate-correctness)
{% /related-card-grid %}
---
id: agent-setup.reference-materials
title: Reference Materials
summary: Connect project knowledge, inspect indexing state, and verify the blocks available to Teammately agents.
kind: reference
product_area: agent_setup
status: stable
updated: 2026-10-30
canonical: /docs/agent-setup/reference-materials
---
# Reference Materials
## Definition
Reference Materials is the Agent Setup workspace for project knowledge that Teammately agents may use. **Materials** manages sources such as websites, Git repositories, and uploaded files. **Indexed Reference** shows the published reference blocks available after extraction and indexing.
Reference Materials is project understanding, not governed correctness. A manual can support an agent's reasoning or an expert Contribution without automatically becoming a policy, rubric, case, or approved statement.
## Fields, states, or lifecycle rules
- A Connection identifies a source and its ingestion or freshness state.
- Website, Git, and file connections follow source-specific discovery and processing paths.
- Indexed Reference presents published blocks rather than a second editable copy of the source.
- Publication is atomic: agents should see a coherent published generation rather than a partially updated index.
- Reconnecting, refreshing, or processing a source can create a newer indexed generation. Completed Runs and Contributions keep their own recorded snapshot boundaries.
- Removing a Connection or source does not imply that previously materialized policies, rubrics, cases, or contribution records should be silently deleted.
- File upload acceptance depends on file type, size, content verification, and the active source-processing path.
## Materials and Indexed Reference
Use Materials to answer: which sources are connected, when were they processed, and does a source need attention? Use Indexed Reference to answer: what text or blocks can agents actually retrieve now? A successful connection is not enough if the expected controlling material never appears in Indexed Reference.
When sources conflict, retain the conflict in the indexed material and resolve correctness through an expert contribution or governed policy. Do not rewrite Project Context to hide source disagreement.
{% example-demo title="Example: reference publication check" %}
A team connects a policy website and a Git repository containing operational rules. After processing, the operator opens Indexed Reference and searches for the current exception clause. The website block is current, while the repository still contains an older rule. The operator keeps both sources visible and requests an expert Contribution to establish the controlling policy.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Product Quickstart](/docs/quickstart)
- [Project Context](/docs/agent-setup/project-context)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}
---
id: admin-console.integrations
title: Workspace Integrations
summary: Connect messaging, repository, trace-store, and training services through their own authorization and operating controls.
kind: reference
product_area: admin_console
status: stable
updated: 2026-10-30
canonical: /docs/admin-console/integrations
---
# Workspace Integrations
## Definition
Open **Admin → Integrations** to connect workspace services. Each connection supplies a specific workflow rather than a general permission to read or write every external resource.
## Fields, states, or lifecycle rules
- Messaging connections support their configured notification and test operations.
- Repository connections discover repositories accessible to the authorizing account.
- Trace-store connections supply their supported capture/import workflow.
- Training connections are selected separately by a Benchmark preparation.
- Connection state, account authorization and a successful downstream operation remain distinct.
## Messaging
Slack and Microsoft Teams have provider-specific connection controls. For Teams, installation and a personal-message test are distinct operations. Workspace settings alone do not confirm installation or that automatic notifications are enabled.
Read provider errors as operational outcomes rather than treating a visible integration card as proof of delivery.
## Repositories and trace stores
GitHub.com, GitLab.com and Bitbucket Cloud connections discover the repositories allowed by the account and installation. Bind the intended repository through Reference Materials and inspect its indexed content.
LangSmith and Langfuse have their own connection surfaces. Keep original record identity and scope when importing material; connected access does not approve the captured behavior.
## Training and inference
Weights training selects an active service connection, supported model and compatible method. Connection checks do not certify quota, create-job permission, storage access or training quality.
Some evaluation paths require an existing callable inference deployment. A training job does not automatically allocate serving resources for every service. The deployment-to-output association can be user-reported where the adapter identifies it that way.
## Credentials and resource boundaries
For setup steps and provider-specific recovery, use the [integration guides](/docs/integrations#connection-setup-guides). Each guide distinguishes workspace connection, Project selection and a successful downstream operation.
Use the provider's owning connection flow and approved secret mechanism. Keep access scoped to the authorized account, identity and resource. Existing Vertex and Baseten training adapters do not authorize Google platform storage, ambient developer credentials or a provider fallback.
A failed service operation should remain actionable in its owning workflow rather than being hidden by a substitute local service.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Export, Train, and Evaluate](/docs/weights-training/exports-and-training)
- [Fieldloop](/docs/fieldloop)
- [Admin Console](/docs/admin-console)
{% /related-card-grid %}