Closure
Request access

Docs · Auth & API keys

Auth & API keys

Identity cuts across every pillar — humans, agents, and API callers all act as accountable members of an org.

Signing in

  • Email + password — accounts use scrypt-hashed passwords with email activation; forgot/reset flows are governed workflows like everything else.
  • Social sign-in — Google, GitHub, X, LinkedIn when configured.
  • OIDC SSO — Enterprise Organizations can require their identity provider.

Access is currently invite-based: request access on the site, and approved Organizations start on a 14-day Team trial. Team members join via invites from Account → Team, with seats enforced per plan.

Sessions are HMAC-signed, httpOnly cookies — no tokens in browser storage.

IDE API keys

Your coding agent authenticates as you, with a key you can revoke.

  1. Console → Account → IDE → mint a key. It's prefixed csk_ and shown once; only a hash is stored.
  2. Put it in your MCP config as STUDIO_API_KEY (see Build in your IDE).
  3. Requests with Authorization: Bearer csk_… act as the sponsoring member — same role, same audit trail.

Every action an agent takes through a key lands in Events attributed to that member. Revoke the key and the agent's access ends immediately.

API access

The same two credentials cover programmatic access:

  • Session cookie — for same-origin and BFF setups where your server logs in and proxies (the SDK's bff mode).
  • Bearer API key — for server-to-server calls to the GraphQL and Workflow APIs.

Never ship either to the browser. The SDK's BFF handlers exist precisely so your frontend talks to your own /api/closure/* routes and credentials stay server-side.

Secrets are not credentials

Connector secrets (CRM tokens, SMTP keys) never travel through chat, MCP arguments, or code. They're collected through governed collect steps in the browser and sealed into the org vault (AES-256-GCM, rotating keyring). Your IDE agent can initiate a connection; only you can complete it.