Authentication and API keys

Sign in

c3 login       # opens the browser; credentials are stored in ~/.c3/
c3 whoami      # user, email, verification status, organisation
c3 logout

New accounts must verify their email address before running jobs, using data or billing. If you miss the email, c3 verify-email sends another. Until then, commands fail with EMAIL_VERIFICATION_REQUIRED.

The dashboard uses the same login.

API keys

Use an API key wherever a browser login is impractical: CI, a shared machine, a coding agent, or billing several people to one organisation.

c3 apikey create ci-runner     # prints the key once: c3_key_...
c3 apikey list
c3 apikey revoke <key-id>

Keys can also be created on the dashboard settings page. A key belongs to the organisation that created it, and jobs submitted with it are owned and billed there.

Use a key

Preferred: an environment variable, from your shell or your CI secret store.

export C3_API_KEY=c3_key_...
c3 deploy

Alternatively, put it in .c3:

api_key: c3_key_...

c3 deploy strips api_key from the copy of .c3 it uploads, so the key never reaches the job. It does not strip anything else. Keep a .c3 that contains a key out of version control.

When several credentials are present, api_key in .c3 wins, then C3_API_KEY, then C3_AUTH_TOKEN, then the saved c3 login session. c3 whoami shows which one is active.

If a key leaks

Revoke it immediately with c3 apikey revoke and create a new one. A revoked key fails with 403.

Coding agents

The MCP server accepts either a browser login (OAuth) or an API key header, depending on the host. See MCP server.