TryMellon
Navigation

Session validation (client-side)

Validate session and check WebAuthn support from the SDK.

Session validation (client-side)

The TryMellon SDK provides client-side helpers to validate the current session and check WebAuthn support before starting a flow.

validateSession(sessionToken)

Use validateSession(sessionToken) to check whether a session token is valid. You must pass the token as an argument; the SDK does not read cookies. This is useful when you have obtained the token (e.g. from your backend via a non-httpOnly cookie or a separate endpoint) and want to avoid showing a login form when the user is already signed in.

// You must obtain the token yourself (e.g. from your backend or a readable cookie)
const sessionToken = '...'; // from your app's session source
const result = await client.validateSession(sessionToken);
if (result.ok && result.value.valid) {
  // User has a valid session; redirect to app or show dashboard
  console.log(result.value.userId, result.value.externalUserId);
}

result is the SDK’s Result<SessionValidateResponse> type — result.ok and result.value are SDK-level wrappers, not JSON fields. The SDK calls GET /v1/sessions/validate with a Bearer token, unwraps the raw { ok, data } envelope transparently, and maps snake_case fields to camelCase (user_iduserId, external_user_idexternalUserId, tenant_idtenantId, app_idappId). If you are calling the REST API directly from a backend, see Backend validation for the raw HTTP contract.

getStatus()

Use getStatus() to detect WebAuthn support in the current browser and environment. This helps you decide whether to show passkey sign-in or fall back to email OTP.

const status = await client.getStatus();
if (status.isPasskeySupported) {
  // Show "Sign in with Passkey"
} else {
  // Show "Sign in with email" or fallback flow
}
// status also has platformAuthenticatorAvailable and recommendedFlow ('passkey' | 'fallback')

When to use client-side vs backend validation

  • Client-side (validateSession, getStatus): Use for UX decisions (show login form or not, show passkey or email). Do not trust these alone for access control.
  • Backend validation: Every protected route and API call must validate the session token on the server. See Backend validation.