pscale: 401 Unauthorized or 403 Forbidden - refresh session or check token

pscale: 401 Unauthorized or 403 Forbidden - refresh session or check token

TL;DR: a 401 means the credential is dead: re-run pscale auth login (or replace the service token) for a fresh one. A 403 means the credential is alive but not allowed: check the token's grants or your org role for the database/branch you targeted. Do not re-login for a 403 — a fresh token with the same grants fails the same way.

401 Unauthorized / 403 Forbidden from pscale

Steps

1. For a 401: run pscale auth login again (interactive) or rotate the service token (CI). Rerun the command. Expected: the 401 is gone.

1. For a 403: open the dashboard and check the service token's grants, or your user's role on the org/database/branch. Add the missing grant.

1. Re-run with the fixed credential. Expected: the command succeeds.

1. If a 403 persists with correct grants, confirm you targeted the right org — tokens are org-scoped and a valid token fails against another org's resources.

When this applies

• 401 Unauthorized on any pscale API call
• 403 Forbidden when the login itself worked
• sudden failures after an org role change

When it doesn't

• Authentication failed on pscale shell — session-level, use the logout/login skill
• network errors or TLS failures
• unknown flag CLI usage errors

Compatibility

pscale CLI; session tokens and service-token grants. Verified against the pscale-auth community skill.

Variant phrasings

• pscale 401 unauthorized fix
• pscale 403 forbidden service token
• planetscale cli token expired

Root cause

401 is authentication (who are you — the credential is invalid), 403 is authorization (what may you do — the credential is valid but unpermitted). They need opposite fixes: refresh vs re-grant.

Edge cases

• an expired session can surface as 401 on one endpoint and 403 on another; check both
• org role demotions revoke access without touching the token
• service-token grants are set at creation; widening needs a new token