Managing API keys

API keys are the bearer tokens your CI and the GitHub Action wrapper use to authenticate against the portal. Each key belongs to a user, works independently of the login cookie, and can be revoked independently.

Creating a key

On /api-keys:

1. Give it a name, freely chosen. Recommendation: what the key does or where it lives, e.g. acme-web-ci. You will see the name later in the overview and in the audit log.
2. Choose a lifetime: 30 days, 90 days, 1 year, or unlimited. Shorter lifetimes are more secure but require more frequent rotation.
3. Click Create.

Copying the plaintext value

Immediately after creation the portal shows the full plaintext of the key once. Copy it right away — we only store a hash, and the plaintext is gone once you close the dialog.

If you have lost the value: simply create a new key and revoke the old one. We cannot show you the value after the fact.

Storing the key in your CI

Save the copied value as a secret in your CI system. Details for each CI system are covered under API keys in secrets.

GitHub Actions quick reference:

Repo → Settings → Secrets and variables → Actions → New repository secret
  Name:   CODECHARTER_API_KEY
  Value:  <the plaintext value>

In the workflow:

- uses: bochmann-software/codeguard@v1
  with:
    api-key: ${{ secrets.CODECHARTER_API_KEY }}

Revoking a key

In the portal API key list, click "Revoke" next to the entry. From the next CI call onwards, the key returns 401 Unauthorized.

There is no "un-revoke" — if you made a mistake, simply create a new key.

Rotating a key

If a key is compromised, or a team member who may have seen the plaintext leaves, rotate it like this:

1. Create a new key in the portal.
2. In your CI system, write the new value into the same secret variable (CODECHARTER_API_KEY).
3. Revoke the old key.

There is no overlap window for zero-downtime rotation — before revoking, briefly verify that the CI system has loaded the new value, and pause builds between steps 2 and 3 if possible.

Multiple keys may be active at the same time; you can therefore keep a second key on hand, for example for a parallel CI system.

What a key can do

A key authorizes read access to all release assets belonging to your subscription. This lets CI workflows pull the installer, CLI binaries per platform, and the VSIX.

What happens when the trial ends

When your subscription has expired, all keys return 403 on the next call. The key remains active but unusable. As soon as the subscription is running again, the key works again without any changes.

Audit

In the API key list you can see per key:

• When it was created
• When it was last used
• How many pulls in the last 30 days
• Current status (active / revoked / expired)

If a key is used suspiciously often or not at all, that is a signal: either revoke it because it is unused, or look more closely at why there are so many pulls.

Multiple keys in parallel

Useful if you have different CI setups — for example one key for the main CI and a separate one for a build server in an isolated environment. This lets you revoke one without affecting the other.

There is currently no hard limit on keys per account, but we reserve the right to introduce one if someone abuses this.