Proctoring SDK vs API vs LMS Plugin: Which Do You Need?

How does the SDK plus API route actually fit together?

Three moving parts, in order. Your backend mints a session, the browser runs it, and your backend reads the report. Here is the whole integration, using only calls from the documented ProctorLink API surface.

// Your backend. Your API key never enters the browser.
POST /v1/sessions
access-token: <YOUR_ACCESS_TOKEN>
secret-token: <YOUR_SECRET_TOKEN>
content-type: application/json

{
  "external_user_id": "candidate-123",
  "exam_id": "math-101-final",
  "attempt_id": "attempt-789",
  "allowed_origins": ["https://exams.yourcompany.com"]
}

// Response
{
  "session_id": "6a7b18df70e4f8ecf2597b6f",
  "session_jwt": "eyJhbGciOi...",
  "expires_at": 1786443201
}

The session_jwt is a short-lived token scoped to one attempt. It is the only thing you pass to the browser. Your access-token and secret-token stay on your server.

npm install @proctorlink/sdk@^0.1.4

import { ProctorLink } from '@proctorlink/sdk';

// jwt and sessionId come from the POST /v1/sessions response above
const session = ProctorLink.createSession({
  jwt: sessionJwt,   // session_jwt
  sessionId,         // session_id
});

session.on('permission', ({ camera }) => {
  if (camera === 'denied') { /* block or warn, your policy */ }
});
session.onEvent((event) => console.log(event.type, event));

await session.start();

// when the attempt finishes:
session.stop();
session.destroy();

In the default flow, recording begins as soon as the camera is granted and the first captured frame becomes the identity reference. That is the entire browser integration.

GET /v1/sessions/6a7b18df70e4f8ecf2597b6f
access-token: <YOUR_ACCESS_TOKEN>
secret-token: <YOUR_SECRET_TOKEN>

// Fetch once status is "validated" (or integrity.analysis_complete is true).
// Before that, face_analysis counts are zero and identity_match is "pending".

Face analysis is deferred, not real-time, so fetch the report once status is validated. If your page sets a Content-Security-Policy, allow the enclave origin so the iframe can mount:

frame-src https://enclave.proctorlink.com;

The enclave origin is listed in the API reference, which is the canonical source if it ever changes.

Why is there no API-only proctoring?

A backend call cannot see the candidate. A browser tab cannot be recorded from your server, so capturing the camera and the browser events always needs code running in the tab. That code is the SDK, which mounts a cross-origin iframe enclave served from ProctorLink’s own domain. The REST API does the two things a server can do: mint the session before the exam, and return the finished report after it.

This has a practical consequence worth stating plainly. If your goal is proctoring with no browser code at all, the API on its own will not get you there. The route for that is the LMS plugin, which bundles the browser half for you. The camera permission binds to the enclave origin rather than your domain, which is why a candidate who has already granted it on one exam is not prompted again on another site that embeds ProctorLink.

Common mistakes when choosing and wiring a route

• Putting your API key in browser JavaScript. The access-token and secret-token are server-side credentials. Anyone holding them can mint sessions billed to your account and read your reports. Fix: mint on your backend and pass only the session_jwt to the SDK.
• Generating a random attempt_id on page load. Resume keys off attempt_id, so a new value on every refresh splits one exam into several sessions and bills the attempt more than once. Fix: derive attempt_id from your own attempt record so it is stable for the attempt.
• Fetching the report the instant the exam ends. Face analysis is deferred, so an immediately fetched report has zero face counts and identity_match of pending. That is an unfinished result, not a clean one. Fix: fetch when status is validated, polling on a sensible interval rather than a tight loop.
• Forgetting the CSP frame-src rule. If your page sets a Content-Security-Policy and does not allow the enclave origin, the iframe cannot mount and capture never starts. Fix: add the enclave origin to frame-src.
• Refreshing a token by tearing the session down. Calling stop() or destroy() to get a new token ends the attempt server-side, so the next mint creates a separate session: two reports for one attempt, billed twice. Fix: handle the token-expired event and call updateToken() with a freshly minted token for the same attempt_id.

Frequently Asked Questions

Next steps

Ready to add proctoring to software you already own? Start with a walkthrough, then pick the route that matches where your exams run.

More Proctoring Guides