PRACTICAL FIELD GUIDE
Handle an email_taken response during signup
An email_taken response means the signup address already exists in that project's user store. The app should handle that outcome deliberately rather than retrying account creation in a loop.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Inspect the status and documented JSON code returned by signup.
- Offer the supported login route when appropriate and preserve a useful error state.
- Verify the behavior with a designated duplicate test address.
What this looks like
ILLUSTRATIVE EXAMPLE
A double-click submits signup twice; the first request creates the user and the second reports a duplicate address.
A boundary to keep clear
Do not invent an automatic account-recovery flow that the current platform does not provide. Plan recovery requirements separately.
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.