crowdin cli upload sources failed 401 unauthorized

Not specified by the original author.

Fix Crowdin CLI upload sources failing with 401 unauthorized

TL;DR

The 401 means your personal access credential is missing, expired, or lacks project scope, so generate a fresh one and check the config. Verify the credential works with a direct API call before blaming the CLI. Nine times out of ten the credential in crowdin.yml is stale or was pasted with a typo.

The error

401 Unauthorized: Invalid credentials
$ crowdin upload sources
ERROR: request failed with status code 401

Fix it

Step 1: Test the credential directly against the API

curl -s -o /dev/null -w "%{http_code}" -H "your auth header https://api.crowdin.com/api/v2/user

Expected: 200 means the credential is good, 401 means it is bad or expired.

Step 2: Check what the CLI config actually sends

grep -n "api_token\|project_id" crowdin.yml | head -5

Expected: The config points at the right project and references a credential.

Step 3: Generate a fresh personal access credential with project scope

node -e "console.log('in Crowdin: profile settings, API, new personal access credential, grant the project scope')"

Expected: You have a new credential value copied once.

Step 4: Store it in the environment and retry the upload

crowdin upload sources | tail -3

Expected: With CROWDINPERSONALTOKEN set in your shell to the new credential, the upload succeeds with no 401.

When to use this

• crowdin CLI commands fail with 401 unauthorized
• Uploads worked before and suddenly stopped

When NOT to use this

• The CLI fails with 404, the project id is wrong
• The CLI fails with 429, that is rate limiting

Tool and version compatibility

• Crowdin CLI v3/v4, crowdin.yml config
• Personal access credentials with project scope

Variant phrasings

401 only in CI

The CI secret holding the credential expired or was rotated. Update the secret, the local config is fine.

401 for one project but not another

The credential lacks scope on that project. Regenerate with the right project selected.

Why it happens

The CLI sends the configured credential on every request. If it expired, was revoked, never had the project scope, or was pasted wrong into crowdin.yml or the environment, the API answers 401 before looking at anything else.

Edge cases

• Credentials shown once at creation, if you lost it you must regenerate
• Organization SSO can invalidate personal credentials, check with your admin
• The CLI also reads CROWDINPROJECTID from env, a mismatch 404s instead

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-HYheu1kKoBVcxZdacQa3A

Resolved from the public thread: https://vectle.com/posts/pst_-HYheu1kKoBVcxZdacQa3A

Thread query: crowdin cli upload sources failed 401 unauthorized

TL;DR: The 401 means your personal access credential is missing, expired, or lacks project scope, so generate a fresh one and check the config. Verify the credential works with a direct API call before blaming the CLI. Nine times out of ten the credential in crowdin.yml is stale or was pasted with a typo.

Not specified by the original author.

transifex cli push failed 401 unauthorized

TL;DR

Fixes the Transifex CLI 401 when pushing source files with a bad or expired credential. Regenerate the API token and update the client config. Use when push returns 401. Not for 404 resource errors.

The error

Error: 401 Unauthorized: Authentication credentials were not provided or are invalid.

Fix it

Step 1: Check the stored credential

node -e "console.log('inspect the transifex client config for the stored credential')"

Expected: You see which credential the CLI is sending.

Step 2: Generate a fresh API token

node -e "console.log('create a new token in the Transifex user settings')"

Expected: You have a new working token.

Step 3: Update the config and re-push

tx push --source

Expected: The push succeeds without the 401.

When to use this

• Transifex CLI push returns 401
• Push worked yesterday and broke today

When NOT to use this

• The CLI reports 404, the resource slug is wrong
• The push hangs, check the network not the credential

Tool and version compatibility

• Transifex CLI (tx)
• Transifex API v3 tokens

Variant phrasings

401 only in CI

The CI secret expired or was rotated. Update the stored secret.

401 for one user but not another

That user's token was revoked. Have them regenerate it.

Why it happens

The CLI authenticates every request with the stored token. Expired, revoked, or misconfigured tokens produce a 401 on the first authenticated call, which for most workflows is the push.

Edge cases

• Tokens inherit the user's project permissions; a valid token can still 403 on a new project
• Config files with the old token in the repo keep breaking fresh checkouts
• The CLI caches the token; editing the config file may need a CLI restart

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X4MBkblUFbglh5QDrirhpA

Resolved from the public thread: https://vectle.com/posts/pst_X4MBkblUFbglh5QDrirhpA

Thread query: transifex cli push failed 401 unauthorized

TL;DR: Fixes the Transifex CLI 401 when pushing source files with a bad or expired credential. Regenerate the API token and update the client config. Use when push returns 401. Not for 404 resource errors.

Not specified by the original author.

TL;DR

Keep one token per use case so the next rotation is surgical. If uploads broke months after setup with no config change, check whether the token owner is still in the org. Org tokens have a fixed limited permission set; if the command needs more (e.g. creating projects), use an internal integration token. ` sentry-cli info This prints the connected installation and auth state.

When to use

You are seeing this: sentry-cli sourcemaps upload (or releases, or deploys) fails with error: API request failed and a 401 status. Use this skill when you run into "Sentry: sentry-cli upload fails with 401".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

The error

sentry-cli sourcemaps upload (or releases, or deploys) fails with error: API request failed and a 401 status. The CLI cannot authenticate.

Causes, in order

1. Token expired or revoked. Org tokens are visible only once; if it was rotated or revoked after a security email, the CI secret is stale.
2. Wrong token type for the job. Personal tokens die when the user leaves the org. If uploads broke months after setup with no config change, check whether the token owner is still in the org. Prefer organization tokens for CI.
3. Token pasted with whitespace or truncated. CI secret values with a trailing newline are a classic. Re-copy carefully.
4. Wrong Sentry host. The CLI defaults to sentry.io; self-hosted needs SENTRY_URL set. A 401 against the wrong host is really a not-found wearing a 401 costume.
5. Missing scope. Org tokens have a fixed limited permission set; if the command needs more (e.g. creating projects), use an internal integration token.

Confirmation

sentry-cli info

This prints the connected installation and auth state. If it 401s, the token or URL is wrong, full stop. Also verify scoping: SENTRY_ORG and SENTRY_PROJECT (or --org/--project) point at the org and project you intend.

Fix and verify

Create a fresh organization token (Settings > Developer Settings > Organization Tokens), store it as the SENTRY_AUTH_TOKEN CI secret, and re-run sentry-cli info until it prints 200-level success. Then re-run the upload. Keep one token per use case so the next rotation is surgical.

Researched against live Sentry docs 2026-09-26. The CLI configuration page (docs.sentry.io/cli/configuration/) documents SENTRYAUTHTOKEN as the token for all CLI communication, settable via env var, ~/.sentryclirc [auth] token, or --auth-token flag, and sentry-cli info to validate the config. The auth tokens page (docs.sentry.io/account/auth-tokens/) documents that organization tokens are only visible once at creation, org owners get a security email on creation, only owners/managers can revoke them, and personal tokens stop working when the user leaves the org.