TPSentinel LogoTPSentinel

Integration Flow

Ordered backend walkthrough from session creation to frontend handoff

Integration Flow

This is the recommended server-side flow when a candidate is about to begin a proctored attempt.

The backend creates the Sentinel resources first, then returns only the values the frontend SDK needs to start.

Create a session in the workspace

When the candidate starts, your backend creates a session inside the correct workspace by calling Create Workspace Session.

This is where you attach the candidate to the attempt and, if needed, provide session-level policy overrides.

Generate a session token

After the session exists, your backend calls Generate Session Token for that session.

The returned token is meant for the frontend SDK, not for your admin integration.

Return frontend-safe config

Your backend returns these values to the frontend:

  • sessionId
  • token
  • orgCode

The frontend then passes them to Sentinel during SDK initialization.

In production, it is usually cleaner to combine the Sentinel calls into one endpoint in your own backend.

For example, your app can expose a single "start proctored attempt" endpoint that:

  1. Creates the Sentinel session.
  2. Generates the Sentinel session token.
  3. Returns sessionId, token, and orgCode to the browser.

This keeps Sentinel admin credentials on the server and gives your frontend one simple handoff step.

For the frontend initialization step after this handoff, continue to Quickstart or JS SDK.

Authentication

Generate and store your Sentinel backend API token

Key Behaviors

Important backend behaviors for candidates and policy handling

On this page

Integration FlowCreate a session in the workspaceGenerate a session tokenReturn frontend-safe configRecommended backend shape