Skip to main content

Overview

The Session API provides methods to access and manage session information after SDK initialization. Session data includes entity identifiers, session tokens, and metadata that persists throughout the verification flow.

Accessing the Session

The session is available through the SDK context after initialization:

Methods

getSessionId()

Returns the current session identifier. Signature:
Returns: string - The unique session ID generated when the session was created. Description: The session ID is a unique identifier for this verification session. It’s used internally by the SDK to maintain state and can be included in support requests or logs to help trace issues. This ID remains constant throughout the session lifecycle. Example:

getEntityId()

Returns the entity ID associated with this session, if available. Signature:
Returns: string | null - The entity ID representing the individual or business being verified, or null if not yet assigned. Description: The entity ID uniquely identifies the person or business undergoing verification in your system. It’s typically set when the session is created on your backend and links the SDK session to a profile in the Frankie platform. Returns null if the session hasn’t been associated with an entity yet (e.g., during initial setup or before verification begins). Use Cases:
  • Reference the entity when calling backend APIs
  • Track entity across multiple verification sessions
Example:

getReference()

Returns the reference identifier for this session. Signature:
Returns: string | null - A custom reference string you provided when creating the session, or null if no reference was set. Description: The reference is an optional custom identifier you can set when generating the session token on your backend. It allows you to link the OneSDK session to your own internal reference system (e.g., application ID, customer ID, transaction ID). This is particularly useful for correlating verification sessions with records in your own database. Example:

isPersisted()

Checks whether the session token was loaded from storage (persisted from a previous initialization). Signature:
Returns: boolean - true if the session was restored from browser storage, false if it’s a newly created session. Description: When you initialize the SDK with persist: true, the session token is stored in browser storage (localStorage or sessionStorage). On subsequent page loads or SDK initializations, the SDK automatically checks for and restores the stored token. This method tells you whether the current session is a restored one or a freshly created one. Use Cases:
  • Determine if a user is resuming a previous verification session
  • Show different UI for new vs. returning users
  • Track session continuity for analytics
  • Decide whether to show onboarding instructions
Example:

unpersist()

Removes the session token from storage. After calling this, the next SDK initialization will not reuse the stored token. Signature:
Returns: void - No return value. Description: Removes the currently persisted session token from browser storage. This is important for security and user privacy - always call this method when:
  • User logs out
  • User explicitly ends their verification session
  • Session expires or becomes invalid
  • User switches accounts
After calling unpersist(), the next SDK initialization will require a fresh token (it won’t automatically restore the old one). Important: This only removes the token from storage; it doesn’t invalidate the session on the server. The session remains valid until it expires or is explicitly invalidated via your backend. Example:

getFrankie2customer()

Returns the frankie2customer flag value. Signature:
Returns: boolean | undefined - The frankie2customer flag value, or undefined if not set. Description: Internal flag that indicates whether this session uses the Frankie v2 API. This is used in specific integration scenarios for customers using the v2 API. Note: This is primarily for internal use and specific partnership integrations. Standard SDK implementations typically don’t need to check this value. Example:

getExtraData()

Returns additional session metadata that may include document requirements and configuration. Signature:
Returns: Object with optional properties containing session metadata. All properties are optional and may be undefined. Description: Extra data contains session-specific metadata that can be set when generating the session token on your backend. This is particularly useful for scenarios where you need to pass custom configuration or context to the SDK. Properties: Example:

getExpirationEpoch()

Returns the session expiration time as a Unix epoch timestamp. Signature:
Returns: number - Unix timestamp in seconds since epoch (January 1, 1970 00:00:00 UTC). Description: Every session has an expiration time after which it becomes invalid. This method returns the exact timestamp when the session expires. You should monitor this value to warn users before expiration or to refresh sessions proactively. Important: The returned value is in seconds, not milliseconds. When using with JavaScript Date, multiply by 1000: new Date(epoch * 1000). Use Cases:
  • Display countdown timer to users
  • Warn users before session expires
  • Automatically refresh/extend sessions
  • Determine if session is still valid
Example:

Session Persistence

When initializing the SDK with persist: true, the session token is stored in browser storage. On subsequent initializations, the stored token takes priority if valid. Important: Even with persist: true, you must still provide a token in the session.token parameter. The SDK will:
  1. Check if a valid stored token exists
  2. If yes and the stored token is valid, use the stored token (it takes priority over the provided token)
  3. If no stored token or stored token is invalid, use the provided token and store it
A stored token is considered invalid if it has a different entity ID, a different customer reference, or has expired. Invalid tokens are rejected gracefully — a warning event is emitted, and the SDK falls back to the provided token. No error is thrown.
No token refresh mechanism. If a session expires mid-flow, there is no way to refresh it. The user must restart the verification flow with a new token obtained from your backend. To avoid this, monitor getExpirationEpoch() and warn users before their session expires.

Enable Persistence

Check and Clear Persistence

Use Cases for Persistence

When to enable:
  • Multi-page flows where users navigate between pages
  • Resumable verification processes
  • Saving progress across browser refreshes
When to disable:
  • One-time verification flows
  • Public/shared device scenarios
  • When security requires fresh sessions each time

Complete Example

Here’s a comprehensive example showing session management in a verification flow:

Session Lifecycle

Best Practices

  1. Always check expiration: Monitor getExpirationEpoch() and warn users before their session expires. There is no refresh mechanism — expired sessions require a new token and the user must restart the flow.
  2. Clear sessions on logout: Call unpersist() when users log out to prevent session reuse.
  3. Log session IDs for debugging: Include getSessionId() in error reports to help support teams.
  4. Use appReference: Set a meaningful appReference during initialization for better tracking.
  5. Handle missing entity IDs: getEntityId() may return null before verification completes.
  6. Validate extra data: Always check if extra data properties exist before using them.

Common Issues

Session expires during verification

There is no token refresh mechanism. If the session expires mid-flow, the user must restart with a new token. Proactively warn users before their session expires to avoid losing progress:

Persisted session not working

Ensure your app has the necessary storage permissions and isn’t running in private/incognito mode: