# API Keys and Delegated Access
Generated: 2026-11-03T06:47:03.438Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: admin-console.api-keys
title: API Keys and Delegated Access
summary: Choose the intended credential capability and keep workspace keys, delegated users, and browser access distinct.
kind: reference
product_area: admin_console
status: stable
updated: 2026-10-30
canonical: /docs/admin-console/api-keys
---
# API Keys and Delegated Access
## Definition
Use **Admin → API Keys** to manage workspace-owned credentials. A credential's base capability, optional restrictions and the destination's current permissions determine what a request can do.
## Fields, states, or lifecycle rules
- The UI offers Full Access, Read Only and Fieldloop Submission.
- The full key value is shown at creation; later lists use a masked value.
- Renaming a key does not broaden its access.
- Changing access requires issuing the intended credential.
- Deleting a key removes its future credential path.
- Expiry and project/action restrictions, when supplied, narrow the base capability.
## Fieldloop Submission
A new Fieldloop key has the workspace-wide Fieldloop submission capability. Its application sender still specifies the intended Project and source. Current workspace, destination and source authority are rechecked by the backend.
Future sources in the same workspace do not require copying the key into every source policy. Existing keys issued with narrower Project or source restrictions keep those restrictions.
Supply the key through the application's approved secret mechanism. This ingestion path does not require CLI login, browser authentication or expanded login grants.
## Delegated developer access
External Agents benchmark operations can also use delegated native login with explicit read/write scopes and current project read/manage permission. That user principal is different from an API-key principal.
Browser cookie authentication remains the interactive app path. Do not substitute a browser cookie for a server credential or assume a delegated token is accepted on every API route.
## Scope and safe handling
Use an explicit organization, Project, Benchmark and Version for the operation. Keep the key out of copied agent tasks, source files, Case materials and logs. A stable resource ID is not an authorization grant.
The supported external contract defines endpoint schemas and required capability. An internal route or a visible key-management screen does not establish an unrestricted customer API.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Capture and Inspect Logs](/docs/fieldloop/ingest-logs)
- [Work with External Agents](/docs/improve/external-agents)
- [Permissions](/docs/reference/permissions)
- [Admin Console](/docs/admin-console)
{% /related-card-grid %}
---
id: fieldloop.ingest
title: Capture and Inspect Logs
summary: Configure a source destination, submit captured application records, and distinguish durable admission from processing completion.
kind: task
product_area: fieldloop
status: stable
updated: 2026-10-30
canonical: /docs/fieldloop/ingest-logs
---
# Capture and Inspect Logs
Capture the application facts that explain a behavior question. Keep the original records until their admission is known.
## Prerequisites
- The intended workspace, Project and Fieldloop source.
- Authorization to submit to that destination.
- Actual captured content and stable application event identities.
- Explicit source processing consent where screening is enabled.
## Submit captured records
Use the source's supported submission path with the configured destination. Application-library calls can submit batches and inspect receipts without installing a CLI or signing in through a browser.
Follow the [Python](/docs/sdks/python), [TypeScript](/docs/sdks/typescript) or [Go](/docs/sdks/go) quickstart for a complete batch example, or use the [Fieldloop REST guide](/docs/public-api/fieldloop).
Provide a Fieldloop submission credential through your application's approved secret mechanism. A newly created Fieldloop key grants that capability across its workspace; the sender still identifies the Project and source. Existing more restricted keys keep their restrictions.
Preserve the exact batch content and idempotency key when recovering an uncertain request. A successful admission does not mean every row has completed processing.
## Inspect Logs
Open Logs, choose the intended time range and source, then inspect the original record, relationships and processing state. Captured messages, context, trajectories and feedback remain distinct fields rather than a synthesized replacement for what happened.
Read receipt counts for accepted, duplicate, conflicting and rejected rows. A processed batch can still contain row-level outcomes that need attention.
## Object and state changes
Submission records durable intake and admits processing work. Processing publishes the captured log and its attributable snapshot. Further analysis can create or update Threads separately.
SDK buffering can acknowledge memory before server admission. It is not a disk outbox or a guarantee of crash delivery. Caller-owned cancellation and recovery should preserve the exact source records and batch identity.
## Success criteria
- Records reached the intended Project and source.
- Original content and event identities are preserved.
- Admission and processing outcomes are understood separately.
- Credentials do not appear in logs, reports or copied tasks.
## Common failure modes
- Using a key for another workspace.
- Re-encoding changed content under the same retry identity.
- Treating receipt polling as a new submission.
- Assuming a captured record was analyzed without source consent.
- Treating temporary client buffering as durable admission.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Fieldloop](/docs/fieldloop)
- [Read Fieldloop Threads](/docs/fieldloop/threads)
- [API Keys and Delegated Access](/docs/admin-console/api-keys)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Fieldloop Intake and Processing](/docs/troubleshooting/fieldloop)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
id: improve.work-evolve
title: Work with External Agents
summary: Copy a benchmark-scoped task for your coding agent to implement and evaluate in your real application repository.
kind: task
product_area: improve
status: stable
updated: 2026-10-30
canonical: /docs/improve/external-agents
---
# Work with External Agents
External Agents gives your coding agent a concrete improvement task grounded in the selected Benchmark Version. The agent works in your real repository; Teammately supplies the applicable Cases, Policies, Rubrics and recorded results.
## Prerequisites
- A selectable Benchmark Version.
- Access to the application repository and authorization for the intended changes.
- A coding agent connected through the setup supplied with the task.
- An optional reference Run that genuinely represents the application starting point.
## Steps
1. Open **Harness improvement → External Agents**.
2. Select the Benchmark Version. Changing it clears local criterion and reference-Run selections.
3. Focus on the whole Benchmark or choose up to 20 approved and applicable Policy and Rubric Versions.
4. Optionally select one individual reference Run. No Run is silently selected.
5. Choose the allowed improvement direction: supported practices, prompt only, model only, the same model family, or model configuration only.
6. Copy the task, including setup instructions when needed, into your coding-agent conversation.
7. Have the agent inspect the actual repository, retrieve the pinned criteria and Run context, implement the change and evaluate it.
8. Inspect resulting Runs through ordinary Benchmark Evaluations.
The copied task includes the Project Agent Brief when present. Credentials do not belong in that text.
## Execution choices
A Teammately Harness and source upload are optional. Customer-executed responses are the default path for the agent's real application. Managed Harness execution requires a deliberate choice.
The product data MCP supplies read-only context, instructions, results and comparisons. The CLI owns local files and submission operations. The documentation MCP only retrieves these manuals.
Start with [CLI authentication](/docs/cli/authentication) and [product MCP setup](/docs/cli/mcp), then follow [external output submission](/docs/cli/external-outputs) or the optional [managed Harness workflow](/docs/cli/managed-harness).
## Object and state changes
The composer keeps selections locally and copies text. It creates no hosted agent Session, transcript, durable handoff object, automatic code adoption or Harness activation. Later submitted responses or managed execution create their own ordinary Run records.
## Success criteria
- The task preserves the intended Benchmark Version and criteria.
- A selected reference Run is checked against actual code.
- Implementation and comparison use actual pre-change and post-change behavior.
- Accepted responses and candidate identity remain attributable.
## Common failure modes
- Stopping after tool setup or context retrieval.
- Assuming a Harness upload is mandatory.
- Treating copied text as an executed Session.
- Using a reference Run from unrelated code.
- Claiming private agent work before returned artifacts or results exist.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Harness Improvement](/docs/improve)
- [Import External Evaluation Outputs](/docs/benchmark-evaluations/output-mapping)
- [Evaluation Results](/docs/benchmark-evaluations/results)
- [Project Context](/docs/agent-setup/project-context)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Output mapping troubleshooting](/docs/troubleshooting/output-mapping)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
id: reference.permissions
title: Permissions
summary: Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access.
kind: reference
product_area: reference
status: stable
updated: 2026-10-30
canonical: /docs/reference/permissions
---
# Permissions
## Definition
Permissions describe the user-facing access boundaries that affect projects, reviewer work, settings, Expert UI access, and organization administration. Use this page to decide which access surface to inspect before diagnosing a blocked workflow.
Role labels describe responsibilities. Use the Admin Console and project access guides for the permission requirements of each action.
## Fields, states, or lifecycle rules
- Project access affects cases, standards, coverage, benchmark work, and project settings.
- Reviewer access affects assigned expert work and reviewer-facing surfaces.
- Organization administration affects members, groups, roles, security controls, API keys, and integrations.
- Role labels in docs should be treated as understandable operating labels, not as exhaustive permission contracts.
- Do not infer auth, security, compliance, tenant isolation, or billing guarantees from this reference.
## Related objects
Permissions should be read with [Admin Console](/docs/admin-console), [Workspaces and projects](/docs/concepts/workspaces-projects), [Permissions troubleshooting](/docs/troubleshooting/permissions), and [Reviewer and Project Access](/docs/governance/reviewer-and-project-access).
{% example-demo title="Permissions boundary" %}
Symptom: A reviewer can sign in but cannot complete assigned case review.
Permission boundary: The issue may be reviewer assignment, project access, Expert UI routing, or missing case context.
Interpretation: Diagnose access and assignment before changing cases, standards, or benchmark results.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Admin Console](/docs/admin-console)
- [Workspaces and projects](/docs/concepts/workspaces-projects)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
- [Expert UI](/docs/integrations/reviewer-workspace)
- [Product Quickstart](/docs/quickstart)
{% /related-card-grid %}
---
id: admin-console.overview
title: Admin Console
summary: Use Admin in the main app to manage workspace access, integrations, API keys, Lemon instructions, and usage.
kind: reference
product_area: admin_console
status: stable
updated: 2026-10-30
canonical: /docs/admin-console
---
# Admin Console
Open **Admin** in the main Teammately app for workspace administration. Project Settings manages project-specific configuration; Benchmark workspaces own datasets, Contributions, evaluation and improvement.
## Definition
Admin groups controls into Directory, Security, Insights, Organization Settings and Integrations. Current destinations include Members, Domain Control, IP Address Control, Private connectivity, Audit Log, Usage Statistics, Lemon instructions, Profile, Support Settings, Integrations and API Keys.
## Fields, states, or lifecycle rules
- Workspace membership and project access are separate boundaries.
- Project membership and an expert's assigned Contribution are separate.
- API-key scope does not make an internal endpoint a supported external contract.
- A connected provider account does not by itself authorize every training or inference operation.
- Recorded usage quantities, processing health and charges have different meanings.
## Choose the owning control
Use Members and the relevant security controls for workspace participation and allowed access. Use Project Settings → Project Members for grants to one Project.
Use Lemon instructions for workspace-level activity guidance. Project overrides take precedence where configured, and change history is automatic.
Use Integrations for messaging, repository, trace-store and training connections. Each service has its own authorization, configuration and operational result. A successful connection check is different from delivery or a completed provider job.
Use API Keys to create a credential for the intended capability. Current types include Full Access, Read Only and Fieldloop Submission. Copy a newly issued value only into the approved secret mechanism.
## Inspect usage
Usage Statistics shows recorded measurements for the chosen date range and workspace processing state. Quantities are not charges. A processing-status failure does not erase already recorded quantities.
Follow the usage guide before interpreting pending processing, credit information or a ledger entry. This surface does not create an invoice or a new retention/compliance guarantee.
## Private connectivity
Private connectivity is available as part of your Teammately deployment. In the main Teammately app, open **Admin → Security → Private connectivity** to learn about AWS PrivateLink, Azure Private Link, or equivalent connectivity for your environment.
Private networking can cover:
- **Your network to Teammately:** private access for sending data, including Fieldloop logs, to Teammately.
- **Teammately to your model endpoint:** private access for model requests and responses.
Private connectivity is arranged as part of your overall Teammately setup. [Ask us](https://teammately.ai/contact) about your deployment.
## Access and authority
Read each permission from its owning surface. A role name used in an orientation page describes responsibility; it is not an exhaustive permission matrix. Approval authority over Policies, Rubrics or Contribution decisions remains with the corresponding workflow.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [API Keys and Delegated Access](/docs/admin-console/api-keys)
- [Workspace Integrations](/docs/admin-console/integrations)
- [Usage Statistics](/docs/admin-console/usage)
- [Project Members](/docs/project-settings/project-members)
- [Lemon Instructions](/docs/project-settings/lemon-instructions)
{% /related-card-grid %}