Keys

An org issues two kinds of key, and neither can do the other’s job. Both live in settings, where any member can list them and an org:admin creates and revokes them, and both show their secret exactly once, on the create response.

API keys

An API key authenticates identify, track, and batch. It is org-level: the source comes from the payload, never the key, so one key serves every app you point at Cowliss. Any member can list them; creating and revoking is org:admin.

cow settings apiKeys create --name "storefront"
cow settings apiKeys list
cow settings apiKeys revoke ak_... --revocation-reason "rotated"

An API key cannot reach the dashboard API at all, including the release lifecycle. Sending one to /v1/releases is a 401, exactly as an unknown key would be.

Deploy keys

A deploy key is the credential a pipeline (or a long-running cow dev) uses to push and deploy without a human session. It reaches five things and nothing else: /v1/project, /v1/artifacts, /v1/releases, /v1/deployments, and /v1/executions.

cow settings deployKeys create --name "ci"
cow settings deployKeys list
cow settings deployKeys revoke ak_... --revocation-reason "pipeline retired"

On those five, a deploy key acts as an admin: it deploys to production, and it cancels a release’s live executions. Everywhere else it is a 401 with no hint that it is a valid credential of any kind: settings, API keys, users, events, segments, and ingestion all refuse it. Revoking one takes effect on its next request: unlike API keys, deploy keys are never cached, because revoking is the whole incident response for a leaked pipeline credential.

So the deploy key is exactly as powerful as your production deploy and no more, and if it leaks nobody reads your customer data with it.

Who can do what

With a signed-in session:

Action	Role
Create the project, upload artifacts, create a release	any member
Deploy to development	any member
Deploy to production	org:admin
Cancel a release’s executions	org:admin
Create or revoke either kind of key	org:admin

The environment comes from the X-Cow-Environment header, and an absent header means production, so a deploy with no environment selected is the one that needs an admin.

Using a deploy key from CI

Set COW_DEPLOY_KEY. Both the CLI and the MCP server prefer it over a cached cow login, so a stale session on the build box can never become the identity a pipeline runs as. cow whoami says which credential is in play.

env:
  COW_DEPLOY_KEY: ${{ secrets.COW_DEPLOY_KEY }}
  COW_ENVIRONMENT: production
steps:
  - run: cow whoami # {"credential":"deployKey",...}
  - run: cow build

The release commands the rest of the pipeline runs are in the projects guide. A member’s own laptop needs none of this: cow login, and everything that follows targets development unless you ask for production.