Skip to main content

​
TL;DR

API keys work for the MCP server — not (yet) for the REST endpoints documented here. A workspace API key (sk_…, generated in Workspace settings → API keys) authenticates against the MCP server, where it can list and call tools. The first-party REST endpoints in these specs accept the session cookie (or the extension bearer token) only — a sk_… key sent to them returns 401. A first-class personal access token (PAT) for the REST API is still on the roadmap.
This is the auth scheme declared on every API endpoint in the OpenAPI specs.

​
How to obtain it

There’s no public POST /login endpoint to call directly. The session cookie is issued by Supabase Auth when a user signs in through the Connie web UI. The flow:
  1. User visits connie.ai and signs in (email + password, OAuth, or magic link)
  2. Supabase Auth issues a signed JWT
  3. The JWT is set as a cookie named session on the connie.ai domain
The cookie carries standard secure attributes — HttpOnly, Secure, SameSite=Lax — so JavaScript can’t read it directly but every API request from the same origin includes it automatically.

​
Using it from a browser

If you’re calling Connie’s API from a logged-in browser session, you don’t need to do anything. The cookie travels with every fetch automatically as long as you set credentials: 'include':

​
Using it from a server

If you’re proxying a user’s request server-side, forward their session cookie:

​
Refresh and logout

Session refresh is handled automatically by the Supabase SSR middleware — your client doesn’t need to refresh tokens manually. Sign-out happens through the Connie UI and clears the cookie.

​
Bearer tokens (extension)

The Connie Chrome extension uses a bearer-token flow because it doesn’t share a cookie jar with the web app.
Token payload: Tokens are issued by Connie when the user authenticates the extension. They’re not currently exposed for general programmatic use.
Builders looking for API keys: if you’re calling the MCP server or the Tools API, use a workspace API key (sk_…) — that’s the supported, server-to-server path today. For the first-party REST endpoints in these specs, a PAT system is still on the roadmap; until it ships the extension token flow is the only programmatic option. Reach out at support@connie.ai if you have a specific integration in mind.

​
HMAC-signed endpoints

A handful of inbound endpoints — webhooks and internal-service callbacks — use HMAC signatures instead of session cookies. These aren’t intended for user-facing API access; they’re called by external services Connie has registered. The Tools module’s Webhooks reference lists every supported provider and the signature scheme each one uses. If you’re sending webhooks into Connie, configure the matching secret in Tools → Webhooks.

​
What to do when auth fails

The API returns predictable errors when auth is missing or invalid. See Errors & rate limits for the full status-code reference. Errors always carry both an HTTP status and a JSON body like { "error": "message", "code": "CODE" } so you can branch on the stable code rather than the human-readable string.