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

# Authentication

> Use a workspace API key, protect credentials, and review actions that change 1eye.

The 1eye MCP server authenticates requests with a workspace API key in an HTTPS header:

```http theme={null}
Authorization: Bearer YOUR_1EYE_API_KEY
```

Send the header to `https://mcp.1eye.ai/mcp`. A production key begins with `1eye_live_`. Use the Bearer header shown here for MCP connections.

## Create and manage a key

Open **Developers → API Keys** in 1eye. Use a descriptive name for each integration so you can identify the key to rotate or revoke later. Key creation and management require the appropriate workspace access; see [API Keys](https://docs.1eye.ai/api-reference/api-keys.md).

The full secret is shown once at creation. Store it in your client's supported secret mechanism or a secrets manager. Environment variable references can keep the literal key out of a shared configuration file.

Never include a key in a URL, public repository, screenshot, prompt, or published example. When sharing diagnostics, redact the `Authorization` header and any environment variable value containing the key.

## Workspace scope

Each call operates on the workspace associated with the API key. The MCP tools do not accept a workspace ID to switch workspaces.

To use another workspace, configure the client with a key from that workspace. Verify the selection with `get_workspace` before running reports or approving changes.

The available MCP catalog describes which operations exist. It does not, by itself, establish a separate read-only API-key scope or a complete role permission matrix. Use your workspace's access controls and your client's tool restrictions as applicable.

## Read tools and changes

The current catalog has 19 read tools and 11 tools that change records or settings. Each change tool's description instructs the assistant to obtain confirmation first.

| Change | Review before approval |
| - | - |
| Knowledge base create, update, or delete | Resource type, record, and exact fields. These settings affect buyer qualification. |
| Workspace profile update | Affected profile fields and new values. |
| Signal settings update | Sources, triggers, and daily limits. These settings affect capture and potential credit use. |
| Pixel domain changes | Domain and complete excluded-URL list. Removal stops tracking that secondary domain. |
| User invitation | Email and role. The invitation sends an email. |
| User name or role update | Person and new values. These fields are shared across that user's 1eye workspaces. |
| User removal | Person and workspace membership being removed. |

Configure the client to ask before writes or restrict the tools available to an agent. The instruction to ask for confirmation depends on client behavior; it is not a server-side authorization guarantee.

For a reporting-only integration, allow only the read tools listed in the tool reference. A client tool restriction controls that client, not the underlying key's access in other integrations.

## Rotate or revoke a key

Use **Developers → API Keys** to rotate or revoke credentials, then update every client that uses the old value. Reconnect and verify the workspace again after updating the secret.

If authentication stops working, check the complete key, its active status, the Bearer header, and whether the client process can resolve its secret reference. See [troubleshooting](https://docs.1eye.ai/mcp/troubleshooting.md).

## Data in your AI client

Tool results can contain buyer contact information, company details, workspace users, and billing information. Those results are returned to the AI client you connect. Review the client's data handling and your organization's requirements before enabling access.


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