> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threetone.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Access and credentials

> Separate API keys, dashboard sessions, provider credentials, and conversation access when preparing an agent integration.

Choose the credential for the operation you are performing. A personal API key, dashboard session, provider secret, and conversation token have different purposes and should not be exchanged as substitutes.

## Credential boundaries

| Credential | Purpose | Where it belongs |
| - | - | - |
| Personal API key | Permitted programmatic API operations. | Server-side integration secret storage. |
| Dashboard session | Signed-in account workflows and dashboard-only management. | The authenticated dashboard. |
| Provider credential | Access to a connected external service. | The supported workspace credential or connection workflow. |
| Conversation token | Access to a particular runtime session where supported. | The supported session workflow, not a replacement for a workspace API key. |

## Server-side API access

Create a scoped key in [workspace API keys](/overview/administration/workspaces/api-keys) and send it in `x-api-key`. Follow the [authentication reference](/api-reference/authentication) for header examples and error handling. Do not send both `x-api-key` and `Authorization` in one request.

Keep the key out of client-side JavaScript, URLs, prompts, screenshots, and logs. Give separate services their own keys so you can revoke one without disrupting unrelated integrations.

## Workspace and resource access

A valid credential does not guarantee access to every workspace resource or operation. Check the workspace, key permissions, and resource access. Tool management and billing administration currently have different credential requirements from ordinary public API reads.

Use [environment variables](/agents-platform/deploy/environment-variables) for supported strings and credential references. A reference identifies a workspace resource; it does not grant a new user or agent permission to use it.

For provider credentials, follow [auth connections](/agents-platform/configure/authentication/auth-connections) or [workspace secrets](/agents-platform/configure/authentication/secrets). A [native integration](/agents-platform/configure/integrations/overview) manages its provider connection through a separate workflow.

## Conversation access

<Note>
  Public conversation token and signed-URL initiation are currently gated in the documented implementation. Agent authentication settings can be represented in configuration, but their presence does not establish a working protected session.
</Note>

The dashboard's preview Security controls are not a verified persisted setup workflow. Do not rely on a preview toggle as proof of authentication enforcement. When a supported runtime path is released, assess token scope, expiry, workspace ownership, and unauthorized access against that release.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Can I put my workspace API key in a web widget?" id="faq-browser-api-key">No. Keep the key server-side. A browser integration needs its own supported session-access design and must not expose a workspace credential.</Accordion>
  <Accordion title="Why can a valid key receive 403?" id="faq-key-forbidden">The key can authenticate while lacking permission, resource access, an allowed source IP, or support for that credential type on the operation.</Accordion>
  <Accordion title="Does a Security toggle mean access is enforced?" id="faq-security-preview">No. A local preview control or stored setting must be distinguished from released runtime enforcement.</Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.