flitz apikey

CI has no browser to sign in with. Instead, your organization has one long-lived API key that pipelines present through the FLITZ_APIKEY environment variable. The apikey group manages that key.

All four need an active license. create, rotate, and revoke additionally require an interactive session — a developer who ran flitz login. Run under FLITZ_APIKEY, they refuse locally, before any network call, with Flitz key management requires an interactive session (exit 3). A pipeline cannot mint, rotate, or revoke its own credential. status is a read and works under any credential.

create

flitz apikey create

Created organization API key:

  <key>

Store it as the FLITZ_APIKEY secret in your CI system — it will not be shown again.

The plaintext is available only in this output. If it is lost, rotate to mint a new one. If a key already exists, create exits 1 with:

An organization API key already exists. Use `flitz apikey rotate` to replace it, or `flitz apikey status` to inspect it.

rotate

flitz apikey rotate

Mints a new key, invalidates the old one, prints the new plaintext once, and reminds you that every pipeline using the old key must be updated with the new value. If no key exists yet, it behaves like create.

revoke

flitz apikey revoke

Revoke the organization API key? Every pipeline using it loses access immediately. [y/N]

The prompt defaults to no. On yes, the key is deleted and the CLI prints Organization API key revoked. and Every pipeline using it has lost access immediately. Revoking is idempotent — it succeeds when no key exists. Answering no (or anything unrecognized) leaves the key in place and fails with the organization API key was left in place (exit 1).

Non-interactively — no terminal to ask on — revoke fails with a usage error (exit 1) unless you pass --yes:

flitz apikey revoke --yes

assume_yes: true in config.yaml answers this prompt too, so with it set, revoke does not ask.

A lapsed license denies the key (and every member) without touching the key itself.

status

flitz apikey status

Organization API key:
  Value:     ****…abcd
  Created:   <timestamp>
  Last used: <timestamp>

or, when there is none:

No organization API key. Run `flitz apikey create` to mint one.

With --json:

{ "present": true, "name": "…", "obfuscated_value": "****…abcd", "created_at": "…", "last_used_at": "…" }

Fields the service does not know are absent. No --json document ever carries a plaintext key.

Using FLITZ_APIKEY in CI

Once, from an interactive session — or from the portal's Settings page — mint the key and store the printed value in your CI system's secret store. Expose it to jobs as an environment variable:

export FLITZ_APIKEY=<organization-api-key>

When FLITZ_APIKEY is set and non-empty, the whole CLI authenticates with it: it is the single credential presented to every licensed action — SDK download, publish, the publish history, the tracks and apps listings, and the plugins group — and the stored sign-in, if any, is never read. flitz login is skipped entirely.

The CLI treats the variable as a secret: it is never echoed, it is redacted in every diagnostic and in the bug-report capture, and it is never written to disk.

A CI job is one command

On a checkout that carries only the committed flitz.yaml:

export FLITZ_APIKEY="$FLITZ_APIKEY_SECRET"
flitz publish --yes --json --track "$BRANCH_NAME"

• --yes lets publish download the pinned SDK unattended when the cache is cold, and create the app when --app or flitz.yaml app: names a key your organization does not have yet. Without it, a non-interactive publish fails fast with a usage error in either case rather than acting by surprise — see On-demand SDK download.
• --track names the track the publish lands on. CI systems usually check out a commit rather than a branch, and the CLI reads no CI variables: with no --track, no track: in flitz.yaml, and no branch, the publish lands on the app's Unassigned track. Pass your CI system's branch variable.
• --json gives the job a parseable result on stdout and nothing else, including the track's "latest" link as track_url.

Where the cache is warmed separately — a cached CI volume, a container image — warm it with flitz sdk use (no argument, reading the committed pin) and then run flitz publish --track "$BRANCH_NAME".

On GitHub Actions, the Flitz GitHub Actions install the CLI and the SDK, publish, and comment on the pull request for you.

A CI job is a first-class non-interactive caller: output is plain (no color, glyphs, or spinners, because stderr is not a terminal), the ambient update notice never runs, no prompt is displayed, and any prompt that would have been asked fails fast naming the flag that answers it.

What works under a key

The local commands — flitz sdk list / path / remove, flitz completions, flitz logout — need no credential at all.

Readiness in a script is flitz status --json; the result of a publish is flitz publish --json; and the exit code, never the prose, says what class of thing went wrong — see Exit codes.