API keys

Issuing one

Who: Any organization member, from API keys in their account menu. Members see and revoke their own; admins see and revoke every key in the organization.
Scope: A key acts as the person who created it, inside their organization, so it grants nothing they do not already have. Domain permissions apply to it exactly as they apply to them.
Lifetime: You choose, up to one year. The key is shown once at creation and stored masked afterwards.
Revoking: From the same page, any time, and it takes effect immediately.

Using one

Keys start with sk-k6-. The CLI reads it from the environment:

Do not paste a key into a command. Literal exports and bearer headers can land in shell history, terminal transcripts, or copied support logs. Load the value from a secret manager, or use a hidden prompt for a short local session.

read -rsp "Cassis API key: " CASSIS_API_KEY
printf '\n'
export CASSIS_API_KEY

The input is not echoed and the secret itself is absent from shell history. For repeat use, replace the prompt with your secret manager’s runtime lookup; keep only the secret reference in scripts.

A non-interactive MCP client sends it as a bearer token to the same endpoint interactive clients use:

curl --fail-with-body \
  -H "Authorization: Bearer ${CASSIS_API_KEY}" \
  https://app.getcassis.com/mcp/

In CI, store it as a secret and expose it as CASSIS_API_KEY. See Set up CI.

Treat a key as the person, not the machine. A key issued by an admin carries admin rights everywhere it is pasted. Issue keys from the account that should own the automation, and revoke rather than reuse when someone leaves.

When you do not need one

Any interactive MCP client that supports OAuth can open a browser for Cassis sign-in and refresh its token automatically. Claude Code, Claude Desktop, and Cursor are examples. See Connect and ask from an MCP client.