Trial Quick Start

Five steps to your first proctored session. Each one links to the full reference if you want the detail — this page deliberately stays short.

Your trial account comes with a fixed number of sessions. The dashboard banner shows how many you have left, and a session that would exceed the budget is refused at start-up rather than part-way through, so you will never lose a candidate's exam to it.

Before You Start

You will need:

• Your trial sign-in, and the tenant slug shown on your dashboard. It looks like trial-a1b2c3d4 and identifies your account to the SDK.
• An application you can add a <script> tag to.

Step 1: Allow Your Application Domain

The SDK only talks to us from origins you have listed. Until you add yours, every session start is rejected by CORS.

Open Network settings and add your application's origin — the scheme and host, for example https://exams.your-company.com. Wildcards like *.your-company.com are accepted for subdomains.

See the Integration Guide for full reference.

Step 2: Create an API Key

Server-side calls — fetching sessions, reading results — authenticate with a bearer token.

Go to API keys and create one. The key is shown once and never again, so store it somewhere safe before you close the dialog. If you lose it, delete it and create another.

See the Integration Guide for full reference.

Step 3: Configure a Webhook

This is the step that closes the loop. Without it you can start sessions and read results in the dashboard, but your own application never finds out what happened — so a trial that skips this has not really tested the integration you would ship.

Add an endpoint at Webhook settings. The default subscription sends you:

Authenticate the callback with HTTP Basic or a named header — both are configured on the same page, and the credentials are encrypted and never shown again. You can also set a signing secret, which adds an X-Proctor-Signature header your endpoint can verify so it knows the call really came from us.

Once the endpoint is saved, use Send test on the same page to check it is reachable and returns a 2xx before a real session depends on it. The test sends a webhook.ping, never a synthetic session event, so it cannot be mistaken for a real one by whatever you have listening.

Delivery is retried on failure, so a brief outage on your side will not lose an event. Each endpoint keeps a delivery history showing what was sent, what your server answered, and a retry button — that is where to look after Step 5 to confirm the callbacks arrived. If you just want to see the shape of the payloads first, point it at any request-capture service.

See the Integration Guide for full reference.

Step 4: Add the SDK to Your Page

The SDK is a script tag, not an npm package — there is nothing to install or bundle.

Copy
<script src="https://proctorsafe-preview-pr-8cd15b4fd3.kieffer.me/sdk/proctor.iife.js"></script>
<script>
  async function startExam() {
    await Proctor.init('trial-a1b2c3d4', 'exam-ref-001', {
      onReady: () => console.log('Proctoring is running'),
    });
  }
</script>

Replace trial-a1b2c3d4 with your own tenant slug and exam-ref-001 with your application's own reference for this exam attempt. That reference must be unique per attempt — it is what ties a session back to your records.

By default we require each session start to be signed, so that nobody else can open sessions against your account. While you are evaluating, the simplest route is the signature helper endpoint described in the guide, which signs with the key we generated for you rather than one you have to manage.

See the Integration Guide for full reference.

Step 5: Run Your First Session

Load the page, allow camera and microphone access when prompted, and complete the short onboarding check. Then open your dashboard — the session appears in the list while it is still running.

During the session you will see a short notice telling you how many trial sessions are left after this one. It appears on trial accounts only and dismisses itself after a few seconds — a full account never shows it.

When it finishes you can open it to see the event timeline, the trust score and how it was reached, and any captures. That view is what your reviewers would use day to day.

If you configured a webhook in step 3, your endpoint will have received session.started as the session opened and session.completed as it ended — that is the full round trip, from your page starting a session to your own system being told how it went. Deliveries and their retries are listed on the webhook settings page if something did not arrive.

See the Integration Guide for full reference.

When Your Trial Runs Out

Sessions beyond your budget are refused with a 402 response and a SESSION_CREDITS_EXHAUSTED code. Retrying will not help, and neither will a new application reference — the budget is per account.

Get in touch when you are ready to continue and we will move you onto a full account. Your existing configuration, keys and sessions carry over.