PRACTICAL FIELD GUIDE
A user token is rejected by another project
App-user tokens are scoped to the project that issued them. Switching API base URLs without switching the user session can produce an authorization failure.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Compare the target project with the authentication flow that created the token.
- Clear stale environment-specific sessions when changing preview or production projects.
- Sign into the intended project and verify the current-user response before loading data.
What this looks like
ILLUSTRATIVE EXAMPLE
A browser moves from a preview app to production while retaining a preview token under a shared storage key.
A boundary to keep clear
Do not treat users with the same email in two projects as the same backend identity.
MCPBackend context
Application email/password authentication is separate from the developer dashboard login and MCP OAuth connection. The current app-user tokens are project-scoped and do not automatically expire. Do not assume built-in refresh, password reset, per-token revocation or social login; check supported behavior before designing those flows.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.