or do you need me to start an email chain

To summarize where we are: the E067011 error you're seeing when trying to start the flow directly with a WebAuthn action (skipping the first screen) is a timing/initialization issue — the webview context isn't fully established when the domain/origin validation fires, so WebAuthn fails before it can even attempt authentication. The button-click flow works because the user interaction gives the webview enough time to initialize properly. Since there's no built-in mechanism in Descope Flows to add a delay before an action or to programmatically skip a screen, here are two paths forward: 1. Bypass flows entirely and call the WebAuthn SDK directly (recommended) Rather than using a flow, you can call the WebAuthn client SDK method directly from your Next.js app:

const descopeSdk = useDescope();
const resp = await descopeSdk.webauthn.signIn(loginId);

This gives you full control over when the call fires — you can gate it behind a

useEffect

that waits for the page to be fully ready, or check that

window.location.origin

is available and matches your configured domain before invoking it. This sidesteps the timing problem entirely. Just verify one thing before you all this that what does

window.location.origin

return inside your webview? In some configurations it can come back as

null

or a

file://

path, which would cause the same origin mismatch regardless of approach. Can you log that value and share what you see? That's likely the root cause and will confirm whether this works as-is or needs additional webview config.

And another approach will be Native biometric gate + pass the refresh token to the webview - If WebAuthn in the webview continues to be problematic, the hybrid approach you originally outlined is a solid fallback: 1. Handle biometric auth natively (LocalAuthentication on iOS, BiometricPrompt on Android) 2. Store the Descope refresh token in Keychain/Keystore 3. On biometric success, pass the token to the Next.js webview via

postMessage

or a URL param 4. In the Next.js app, call

descope.refresh(refreshToken)

to re-establish the session This completely avoids WebAuthn-in-webview issues. The trade-off is it requires native code changes on both platforms — but it's the most reliable path if the webview origin issue is a hard limitation.

Please let me know if this resolve the issue

To give you more details, here is a simplified version of our

SignIn

component:

const descope = useDescope()
const [shouldShowForm, setShouldShowForm] = useState(false)

useEffect(() => {
    // adding a delay doesn't change anything
    setTimeout(async () => {
        const lastAuth = JSON.parse(localStorage.getItem("dls_last_auth"))
        const descopeResponse = await descope.webauthn.signIn(lastAuth.loginId)
        if (descopeResponse.ok) {
            router.push("/home")
        } else {
            setShouldShowForm(true)
        }
    }, 3000)
}, [])

return shouldShowForm ? <Descope ... /> : <Spinner />

In this case,

descopeResponse

is always:

{
  "code": 403,
  "ok": false,
  "response": {},
  "error": {
    "errorCode": "E067011",
    "errorDescription": "Missing domain in WebAuthn settings"
  }
}

The

AuthProvider

does include the

baseUrl

we defined in the Descope console, and the

SignIn

component is a children of it:

<AuthProvider
  projectId={process.env.NEXT_PUBLIC_DESCOPE_PROJECT_ID!}
  sessionTokenViaCookie={{ sameSite: 'Lax' }}
  refreshTokenViaCookie={{ secure: process.env['NODE_ENV'] !== 'development' }}
  persistTokens={true}
  storeLastAuthenticatedUser={true}
  baseUrl="<https://auth.amaebetter.com>"
>

We used this URL and the

SignIn

component (without the

useEffect

) for a while and didn't face any issue.

We're creating a dedicated preview subdomain in order to test this as if I understand correctly, this can't work otherwise. We'll get back to you if this still doesn't work.