Skip to main content
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 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
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.

1. Generate the key

In connie.ai:
1

Open Workspace settings

Click your workspace name in the sidebar → Settings.
2

Go to API keys

API keys in the settings nav → Create key.
3

Copy the key

The sk_… value is shown once. Copy it now — closing the modal means generating a new key.

2. Configure your MCP client

The key goes in the Authorization: Bearer header. Two forms work everywhere; pick based on what your client supports.
For clients that speak HTTP+MCP directly (Claude Desktop, anything with native remote-MCP support):
No ?client= alias needed — workspace API keys don’t go through OAuth’s Connected Apps registry, so they share no cache with other entries.
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

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

OAuth (for IDEs)

For human-driven IDE use. Per-user audit logs, fluid multi-workspace access — but never for automation.

Troubleshooting

401 errors, header propagation, rotation gotchas.