Skip to main content
An API token authenticates CLI commands, scripts, and automation without an interactive browser session. You create a personal token for your own CLI access, or an organization token for automation that should belong to the workspace rather than an individual user account.

​
Choose personal or organization scope

Token type determines ownership. Use the smallest owner boundary that fits the job.

Personal token

Use for your workstation and one-off CLI tasks. A personal token follows your user account and works across any licensed workspace you belong to.

Organization token

Use for CI/CD pipelines, scheduled jobs, and shared automation. An organization token is scoped to the single workspace where you create it and keeps working even when teammates change roles or leave.
Do not use a personal token for shared infrastructure. If the token owner loses their license, changes roles, or leaves the organization, automation using their personal token will stop working. Use an organization token so the credential belongs to the workspace, not the person.

​
Create a token

Dashboard-created tokens require a name, one or more scopes, and an expiration date.
1

Open the token page

For a personal token, go to Account Settings → Tokens. For an organization token, go to Organization → API Tokens.
2

Name the token descriptively

Use a name that identifies the owner and workload — for example, local-dev-zara, github-actions-prod, or nightly-replay-check. A clear name makes the token table easier to audit later.
3

Choose scopes

Select at least one scope. read lets the token view buckets and forwarders. write lets the token manage forwarders, such as pausing, resuming, or disabling them.
4

Set an expiration

Choose 7 days, 30 days, 90 days, 1 year, or Never. The dialog defaults to 90 days. Prefer a time-bounded expiration for anything used in automated workflows.
5

Copy the token immediately

The full token value is shown only once. Copy it to your password manager, keychain, or CI secret store before you close the dialog.
Repost stores a hash of your token and displays only the first 11 characters afterward — for example, rp_12345678.... The full token cannot be revealed once the creation dialog closes.

​
Token format

Every Repost API token starts with rp_ and is exactly 43 characters long. The dashboard table shows only the first 11 characters so you can identify a token without exposing the secret value.

​
Store your token securely

Keep the full token value in a secure location before closing the creation dialog.

Password manager

Store the token in 1Password, Bitwarden, or your preferred password manager alongside a note describing the workload it authenticates.

System keychain

Use macOS Keychain, GNOME Keyring, or an equivalent OS-level secret store for tokens on development machines.

CI secret store

Add the token as an encrypted secret in GitHub Actions, GitLab CI, CircleCI, or whichever CI platform your pipeline runs on.

​
Use tokens with the CLI

Use repost auth token to save the token in the CLI’s local credential store. Run repost auth status after storing it to confirm the token validates correctly with Repost.
REPOST_TOKEN always overrides a stored token. When you need to test locally with a specific token, set the environment variable in your shell rather than re-running repost auth token.

​
Read the token table

The token table is your inventory of all active and expired tokens for your account or organization.

​
Rotate a token

Rotate tokens on a schedule or any time you suspect a token has been exposed.
1

Create the replacement token first

Create the new token and add it to your CLI, CI secret store, or workload configuration before revoking the old one.
2

Verify the new token works

Run repost auth status or the command your automation depends on to confirm the new token authenticates correctly.
3

Revoke the old token

Open the token’s actions menu and choose Revoke token. Any application still using the old token loses access immediately.
Revoked tokens are removed from the active token table. Expired tokens remain visible with an expired status until you revoke them manually.

​
Troubleshoot token failures

REPOST_TOKEN overrides locally stored credentials. If you set this environment variable and then ran repost auth token to store a different token, the environment variable still wins. Clear REPOST_TOKEN from your shell to use the stored credential.
repost auth logout removes locally stored credentials. It does not unset the REPOST_TOKEN environment variable in your shell or CI job. Later commands continue to prefer the environment value while it exists.
Create a replacement token and update the workload. Expired tokens fail validation and remain visible in the table with an expired status until you revoke them.
Revocation is immediate and permanent. Revoked tokens are removed from the active token table and fail all future validation requests.
Organization tokens are scoped to a single workspace. If the token was created in workspace A, CLI commands targeting workspace B will fail. Create the token from the workspace that owns the buckets and forwarders your job needs.
Personal tokens inherit the permissions of the token owner. If you are not licensed in a particular workspace, CLI commands targeting that workspace will fail until an owner or admin assigns you a seat.