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:
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:
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
getReference()
Returns the reference identifier for this session.
Signature:
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:
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
unpersist()
Removes the session token from storage. After calling this, the next SDK initialization will not reuse the stored token.
Signature:
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
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:
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:
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:
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
Session Persistence
When initializing the SDK withpersist: 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:
- Check if a valid stored token exists
- If yes and the stored token is valid, use the stored token (it takes priority over the provided token)
- If no stored token or stored token is invalid, use the provided token and store it
warning event is emitted, and the SDK falls back to the provided token. No error is thrown.
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
- 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
-
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. -
Clear sessions on logout: Call
unpersist()when users log out to prevent session reuse. -
Log session IDs for debugging: Include
getSessionId()in error reports to help support teams. -
Use appReference: Set a meaningful
appReferenceduring initialization for better tracking. -
Handle missing entity IDs:
getEntityId()may return null before verification completes. - Validate extra data: Always check if extra data properties exist before using them.