Docs · Keys

Keys authenticate every install

Installs are authenticated with a per-user API key. Keys are free, issued during onboarding and from your account page, and shown exactly once. Here is how they work and how to look after them.

Getting a key

Create and store a key

Your first key is issued during onboarding after you sign in with GitHub. You can create more, or replace a lost one, from your keys page. A key is shown in full exactly once at creation: only a short prefix and a hash are stored, so we can recognise a key on use but can never show it to you again. Store it in a secret manager, not a chat log.

Each account can hold up to five active keys at once. Keys begin with skp_live_ so secret scanners can spot them if one leaks.

skillport login

$npx @skillporthq/cli@latest login

Running login validates the key against the marketplace and writes it to ~/.skillport/config.json with owner-only permissions (0600 on POSIX systems).

How the CLI finds it

Key resolution order

The CLI resolves your key in this order, so CI can override a stored key without touching your config file:

The --key flag on the command
The SKILLPORT_API_KEY environment variable, recommended for CI
~/.skillport/config.json, written by skillport login

ci install

$SKILLPORT_API_KEY=skp_live_… npx @skillporthq/cli@latest add anthropic-oss/pdf-tools

What a key unlocks

Entitlements and installs

When you install, the download service checks three things before it issues a short-lived, checksum-verified download link: that your key is valid, that the version is published, and that you hold an entitlement for the skill. Free skills grant an entitlement automatically on first install. Paid skills require a licence; if you do not hold one, the error carries the purchase link rather than failing silently. Every download is recorded as an append-only event tied to the key that made it, which is what powers your install history.

If a key leaks

Revoking a key

Revoke a key from your keys page the moment you suspect it is exposed. Revocation takes effect on the next install request, and revoking one key never affects the others. Because only a prefix and a hash are stored, rotating a key is the safe default whenever you are unsure.

Keep keys out of logs

The CLI never echoes your key. Prefer SKILLPORT_API_KEY as a masked CI secret over passing --key on a command line that a shell history or CI log might capture.

Teams

Shared keys for CI

Organisation-owned keys and licences, so a team can share entitlements and run installs from a single CI key, are part of the enterprise work in progress. Today keys and entitlements are per user. If you need shared installs now, a dedicated service account with its own key is the honest interim.

Put a key to work

The CLI reference covers every command, the install targets per agent, the lockfile, and the errors you might see.