QuantumNous/new-api · error · Error
Failed to start verification
Error message
Failed to start verification
What it means
Fallback thrown in verifyPasskey() when the call to beginPasskeyVerification(scope) (the begin endpoint) responds with success falsy and no message. The server refused to start the WebAuthn ceremony, so no credential request options were produced. The server's message, when present, replaces this generic string.
Source
Thrown at web/src/features/auth/secure-verification/api.ts:139
return res.data.data
}
/**
* Perform Passkey verification flow.
*/
async function verifyPasskey(
scope: SecurityProofScope
): Promise<SecurityProof> {
if (typeof navigator === 'undefined' || !navigator.credentials) {
throw new Error(
i18next.t('Passkey verification is not supported in this environment')
)
}
try {
const beginResponse = await beginPasskeyVerification(scope)
if (!beginResponse.success) {
throw new Error(
beginResponse.message || i18next.t('Failed to start verification')
)
}
const publicKey = prepareCredentialRequestOptions(
beginResponse.data?.options ?? beginResponse.data
)
const flowToken = beginResponse.data?.flow_token
if (!flowToken) {
throw new Error(i18next.t('Verification flow expired'))
}
const credential = (await navigator.credentials.get({
publicKey,
})) as PublicKeyCredential | null
if (!credential) {
throw new Error(i18next.t('Passkey verification was cancelled'))View on GitHub (pinned to e2c7aa7b10)
Solutions
- Inspect the begin request's response body — the message usually says whether it is 'no passkey registered' or a config error.
- Confirm the user actually has a registered passkey (offer 2FA as fallback).
- Check backend WebAuthn/RP ID and origin configuration matches the current domain and scheme.
- Re-authenticate if the session expired, then retry.
Defensive patterns
Strategy: try-catch
Try / catch
try {
const proof = await verify('passkey', scope)
return proof.proof_token
} catch (e) {
const msg = getErrorMessage(e)
if (/not registered|no passkey/i.test(msg)) {
switchTo2FAMethod() // graceful fallback
} else {
toast.error(msg)
}
} Prevention
- Only offer passkey verification when the account has a registered passkey (query status first)
- Keep backend RP ID/origin config in sync with the serving domain
- Propagate server messages so users see the real reason, not the fallback
When it happens
Trigger: POST to the passkey begin endpoint failing server-side: no passkey registered for the account, invalid/expired session, backend WebAuthn config (RP ID/origin) broken, or the scope has no pending operation.
Common situations: User tries passkey verification but never registered a passkey; backend relying-party origin changed after a domain migration so stored credentials no longer match; session cookie lost mid-flow.
Related errors
- Passkey verification was cancelled
- Passkey verification failed
- Failed to initialize OAuth
- Passkey verification is not supported in this environment
- Verification flow expired
AI-assisted analysis of QuantumNous/new-api@e2c7aa7b10 (2026-08-15).
Data as JSON: /api/errors/0a369ca0bc365fdf.
Report an issue: GitHub.