Getting Started
What Sentinel is and how the core pieces fit together
Getting Started
The integration has three main parts:
- Your backend
- Sentinel API
- Sentinel frontend SDK
Your backend decides who is being proctored and when a session should begin. The Sentinel API stores workspaces, sessions, policies, events, and captured evidence. The Sentinel frontend SDK runs in the browser and powers the candidate-side proctoring flow.
Core entities
The main resource chain looks like this:
Workspace -> Session -> SessionToken -> Event / ArtifactWorkspace: A folder for proctoring policy and grouped sessions. You can map one course or exam to a workspace, and then create each student attempt as a session under that workspaceSession: One candidate's proctored attemptSessionToken: Authentication provided to the frontend SDK while it posts events and artifacts from the student's browser during proctoringEvent: Something that happened during the sessionArtifact: Captured evidence such as a snapshot or recording
How the pieces fit together
Your backend creates a workspace
The workspace groups sessions together and stores the default proctoring policy for a course or exam.
Your backend creates a session
Each student attempt becomes a separate session under that workspace.
Your backend creates a session token
The session token is then passed to the frontend SDK for that student session.
The frontend starts Sentinel
The SDK uses the session details to begin setup and start browser-side proctoring.
Sentinel captures events and artifacts
During the session, Sentinel records activity and captures evidence based on the configured policy.
For the full end-to-end integration flow, continue to Quickstart.