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

# Workspace API key

> The non-OAuth path. One static key, one workspace — for automations, CI jobs, and shared bots that don't have a human in the loop.

A workspace API key is a static `sk_*` token tied to one workspace. **For any non-human caller, this is the path you should use** — scheduled jobs, CI workflows, shared internal bots, anything running on a server. The [OAuth path](/mcp/quickstart) exists for IDEs where a human is in the driver's seat; it is not the right choice for automation.

## Why automation should always use an API key, never OAuth

OAuth grants are *user-scoped*: one token covers every workspace the authorizing human belongs to. That's the right shape for a developer running Cursor — they consent, they hit Revoke when they're done. For an unattended automation it's a footgun: a leaked OAuth refresh token gives an attacker access to every workspace the user belongs to, not just the one workspace the automation actually needed.

A workspace API key is *workspace-scoped*. Leak it and the blast radius is exactly one workspace's data — not the personal workspace next door, not the prod workspace a teammate gave the user read access to last quarter. Smaller blast radius is always the right default for credentials a machine holds.

Use the API key path for:

* A scheduled job that runs nightly
* A CI workflow that calls Connie as part of a release
* A shared internal bot that anyone on the team can drive
* An MCP-aware tool you're building that runs on a server, not a laptop

<Warning>
  Anyone with this key can call Connie as that workspace. Store it like a database password — a secrets manager, a CI secret, never committed to git. Rotate immediately if it leaks.
</Warning>

***

## 1. Generate the key

In [connie.ai](https://connie.ai):

<Steps>
  <Step title="Open Workspace settings">
    Click your workspace name in the sidebar → **Settings**.
  </Step>

  <Step title="Go to API keys">
    **API keys** in the settings nav → **Create key**.
  </Step>

  <Step title="Copy the key">
    The `sk_…` value is shown **once**. Copy it now — closing the modal means generating a new key.
  </Step>
</Steps>

***

## 2. Configure your MCP client

The key goes in the `Authorization: Bearer` header. Two forms work everywhere; pick based on what your client supports.

<Tabs>
  <Tab title="Native HTTP clients">
    For clients that speak HTTP+MCP directly (Claude Desktop, anything with native remote-MCP support):

    ```json theme={null}
    {
      "mcpServers": {
        "connie": {
          "url": "https://mcp.connie.ai/api/mcp",
          "headers": {
            "Authorization": "Bearer sk_<your-workspace-key>"
          }
        }
      }
    }
    ```

    No `?client=` alias needed — workspace API keys don't go through OAuth's Connected Apps registry, so they share no cache with other entries.
  </Tab>

  <Tab title="Stdio bridge (mcp-remote)">
    For stdio-only clients (Cursor, Claude Code, Windsurf), pass the header through the bridge:

    ```json theme={null}
    {
      "mcpServers": {
        "connie": {
          "command": "npx",
          "args": [
            "-y",
            "mcp-remote",
            "https://mcp.connie.ai/api/mcp",
            "--header",
            "Authorization: Bearer sk_<your-workspace-key>"
          ]
        }
      }
    }
    ```

    No positional port arg is needed in this mode — there's no OAuth callback to receive, so `mcp-remote` doesn't open a local listener.
  </Tab>
</Tabs>

Save the config and fully restart your client. The first MCP request flows straight through; no browser opens, no consent screen.

***

## Trade-offs vs OAuth

| | **Workspace API key** | **OAuth** |
| - | - | - |
| **Identity** | Anonymous to the workspace — every call from this key looks identical | Tied to the human who authorized |
| **Audit log** | All actions attributed to "the workspace bot" | Per-user `user_id` on every event |
| **Scope** | One workspace | The user's identity, across every workspace they're in |
| **Lifetime** | Until manually rotated | 1h access + 30d refresh, rotates automatically |
| **Revocation** | Rotate the key in workspace settings (all clients using it lose access) | Per-client **Revoke** in Connected Apps |
| **Multiple workspaces** | One key per workspace | One grant covers all |
| **Setup cost** | One-time paste | One-click browser flow on first use |

The table is descriptive, not prescriptive. For non-human callers, the API key is the right choice for the security reason above (smaller blast radius on leak), not because it scores higher on per-row attributes. OAuth's "lifetime: 1h + 30d auto-rotating" looks attractive in isolation but doesn't help you when the leaked credential exposes N workspaces at once instead of one.

***

## Rotation and revocation

To kill a key (compromise, role change, team rotation), open **Workspace settings → API keys**, find the row, and click **Rotate** — Connie generates a new `sk_…` and invalidates the old one immediately. Every MCP client using the old key starts getting `401 Unauthorized` on its next request.

There's no "pause" or per-client revoke for workspace keys — they're a single shared credential. If you need per-client granularity, that's exactly what OAuth gives you.

***

## What's next

<CardGroup cols={2}>
  <Card title="OAuth (for IDEs)" icon="user-check" href="/mcp/quickstart">
    For human-driven IDE use. Per-user audit logs, fluid multi-workspace access — but never for automation.
  </Card>

  <Card title="Troubleshooting" icon="life-ring" href="/mcp/troubleshooting">
    401 errors, header propagation, rotation gotchas.
  </Card>
</CardGroup>


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