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
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 theAuthorization: Bearer header. Two forms work everywhere; pick based on what your client supports.
- Native HTTP clients
- Stdio bridge (mcp-remote)
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.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 newsk_… 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.