Settings

Access Tokens

Account-level access tokens authorize Skytells apps, the CLI, and third-party integrations to act on your account. Create, scope, and revoke them from Settings in the Skytells Console.

Access tokens are account-level credentials. When a Skytells application — such as the Skytells CLI, a connected integration, or an automated pipeline — needs to interact with your account, it authenticates using an access token. The token tells Skytells: "this request is authorized to act on behalf of this account."

This is the authorization layer beneath every CLI command, every automated deployment, and every integration that operates without a browser session. Tokens are not browser sessions — they are durable credentials that represent delegated account access.


How tokens work

When you create a token and provide it to an application:

  1. The application sends the token with each API request.
  2. Skytells validates the token against your account and its assigned scopes.
  3. If valid and in-scope, the request proceeds as your account.
  4. If expired or revoked, the request is rejected immediately.

The token never exposes your password or session. It is a discrete, revocable key to a defined slice of your account's capabilities.


The CLI and access tokens

The Skytells CLI authenticates using an access token. When you run skytells login, the CLI either:

  • Opens a browser-based OAuth flow that issues a token automatically, or
  • Prompts you to paste a token you have created manually in Settings.

That token is stored locally by the CLI and sent with every command. If you revoke the token, the CLI loses access immediately — no other credentials are affected.

For CLI authentication setup, see CLI Authentication.


When to use tokens

SituationCredential
CLI access on a developer machineAccess token — created in Settings or via skytells login
CI/CD pipeline (GitHub Actions, GitLab, etc.)Access token — narrow scope, stored as a CI secret
Automated deployment scriptsAccess token — scoped to deployment operations
App or integration authorizing on behalf of a userAccess token — issued through OAuth or created manually
Legacy SDK requiring a classic secret keyAPI Key
Your own OpenAI / Anthropic key inside the ConsoleBYOK Provider

How to get here

  1. Open the Skytells Console and navigate to Settings in the left sidebar.
  2. Select Tokens in the Settings left rail.

Creating an access token

  1. On the Tokens page, click Create token or the equivalent action.
  2. Name it for its consumercli-macbook-alice, github-actions-prod, deploy-pipeline-staging. A name that identifies who or what holds the token makes revocation obvious later.
  3. Assign scopes — select the minimum set of permissions the consumer actually needs. A deployment pipeline does not need billing access; a read-only monitoring integration does not need write access.
  4. Set an expiration — choose a validity window appropriate to the use case. Short-lived tokens for temporary access; longer windows for persistent service credentials with scheduled rotation.
  5. Confirm creation.
  6. Copy the token value immediately. It is shown once. After you leave the page, only a masked identifier is visible. Store it in a secrets manager, a CI/CD secret store, or an encrypted environment variable.

There is no way to retrieve the full token value after creation. If you lose it, revoke the token and create a new one.


Managing tokens

The Tokens page lists every active token on your account — name, scopes, creation date, expiration, and last-used indicator. From here:

ActionWhen to use it
View detailsConfirm which consumer holds which token, check expiration.
RevokeImmediately invalidate the token. Any app or CLI using it stops working at once.

Rotating a token

Rotate tokens on a regular schedule, or immediately if a token is exposed in logs, a commit, or any unintended location:

  1. Create a replacement token with a clear name (github-actions-prod-2) and the same or narrower scopes.
  2. Update the consuming app, CLI config, CI secret, or environment variable with the new token.
  3. Verify the new token works end-to-end.
  4. Revoke the old token.

Do not delay the revocation. A token that exists can be used.


Security practices

  • Least privilege — scope each token to exactly what the consumer needs. Narrower scope means a stolen or leaked token has limited impact.
  • Short expiration for temporary work — debugging, staging access, one-off automations.
  • Rotate long-lived tokens on a schedule — even without a known exposure.
  • Revoke when the consumer is decommissioned — when a developer leaves, a CI pipeline is retired, or an integration is removed, revoke its token.
  • Never commit tokens to source control — even in private repositories. Use environment variable injection or a secrets manager.

For account-wide security practices, see Security. For the platform's authentication model, see Authentication.


How is this guide?

On this page