Proctor SDK

Vue integrations can use the first-party UI components instead of wiring recorder state by hand. Render them inside ProctoredAssessment, then save the returned clipNumber or playback state in your assessment answers. For Storybook or non-proctored previews, AudioPlayer and VideoPlayer can also run without a client; they use local browser playback with the same UI events but no SDK telemetry.

<script setup lang="ts">
import { AudioPlayer } from "@a4anthony/proctorkit-vue";
import "@a4anthony/proctorkit-vue/style.css";
</script>

<template>
  <AudioPlayer
    url="/audio/listening-01.mp3"
    label="Question 5 listening audio"
    :allowed-replays="2"
    @ended="markPromptListened"
  />
</template>

<script setup lang="ts">
import {
  AudioPlayer,
  VideoPlayer,
  AudioRecorder,
  VideoRecorder,
} from "@a4anthony/proctorkit-vue";
import "@a4anthony/proctorkit-vue/style.css";
</script>

<template>
  <ProctoredAssessment
    app-id="pk_live_xxx"
    correlation-id="client-attempt-123"
    :candidate="candidate"
    preset="standard"
  >
    <template #default="{ client }">
      <AudioPlayer
        :client="client"
        :url="question.audioUrl"
        label="Question 5 listening audio"
        :allowed-replays="2"
        :autoplay="false"
        @ended="markPromptListened"
      />

      <VideoPlayer
        :client="client"
        :url="question.videoUrl"
        label="Question 7 viewing prompt"
        :allowed-replays="1"
        @ended="markPromptWatched"
      />

      <AudioRecorder
        :client="client"
        title="Speaking answer"
        :max-duration-ms="120000"
        @uploaded="({ clipNumber }) => saveAnswer({ clipNumber })"
        @dropped="({ reason }) => showUploadError(reason)"
      />

      <VideoRecorder
        :client="client"
        title="Video answer"
        :max-duration-ms="120000"
        :stream="candidateCameraStream"
        :video-bitrate="1500000"
        @uploaded="({ clipNumber }) => saveAnswer({ clipNumber })"
        @dropped="({ reason }) => showUploadError(reason)"
      />
    </template>
  </ProctoredAssessment>
</template>

Pass stream when your assessment already owns microphone/camera access. The video component previews the stream but leaves track lifecycle ownership with your app.

For listening and viewing prompts, allowedReplays controls how many extra plays are allowed after the first playback. Both players render a custom progress bar, support autoplay attempts, and hide pause/stop controls by default. While a prompt is actively playing, the Play button is hidden; after playback ends, a Replay button appears only when another replay is allowed. Neither player exposes seeking, so candidates cannot skip through a prompt. Pass client in a live proctored session; omit it for isolated Storybook assessment screens. ProctoredAssessment carries the preflight speaker/headphone selection into the SDK session, and both players also accept sinkId for an explicit output override. VideoPlayer additionally accepts poster, muted, and playsInline (default true); pair autoplay with muted because browsers block un-muted video autoplay without a candidate gesture.

AudioPlayer props

VideoPlayer props

VideoPlayer uses playVideoFile and emits the same events as AudioPlayer. Its full prop list is the shared playback props plus three video-only props.

AudioRecorder props

While a clip uploads (and during the brief pre-record preparation), the card shows a spinner with Uploading… / Preparing….

Upload audio clips to your own backend

Pass sendClip to mirror each finalized clip to your own storage or API in addition to the proctoring server. Your function receives the recorded audio as a Blob plus { mimeType, durationMs, clipNumber }; resolve when your upload succeeds and throw when it fails. The mirror runs in parallel with the proctoring-server upload and is best-effort: a failure never changes the clip outcome — uploaded still fires, and the rejection surfaces on clip-mirror-failed rather than dropped. It is attempted once per clip, so own any retry inside your function (use clipNumber as an idempotency key).

<script setup lang="ts">
import { AudioRecorder } from "@a4anthony/proctorkit-vue";
import type { MediaClipDataSink } from "@a4anthony/proctorkit-vue";

const sendClip: MediaClipDataSink = async ({ blob, durationMs, clipNumber }) => {
  const form = new FormData();
  form.append("audio", blob, `clip-${clipNumber}.webm`);
  form.append("durationMs", String(durationMs));

  const res = await fetch("https://api.example.com/answers", {
    method: "POST",
    headers: { authorization: `Bearer ${token}` },
    body: form,
  });
  if (!res.ok) throw new Error(`http_${res.status}`); // throw = mirror failed
  // resolve = mirror succeeded
};

function onMirrorFailed({ clipNumber, message }) {
  // The clip is still safely stored on the proctoring server.
  console.warn(`Clip #${clipNumber} mirror failed: ${message}`);
}
</script>

<template>
  <AudioRecorder
    :client="client"
    :send-clip="sendClip"
    @uploaded="onUploaded"
    @clip-mirror-failed="onMirrorFailed"
  />
</template>

Handling recorder errors

The recorder reports failure through two separate events, because they need different candidate messaging:

• error — recording never produced a clip (the microphone couldn't be acquired or started). Nothing was captured.
• dropped — the clip recorded but couldn't be stored (the upload failed, or it captured nothing). Like a dropped network packet: it existed, then didn't reach its destination.

Both carry a stable code beside the human-readable message. Branch on the code, not the message — messages come from the browser and vary by locale. Codes are validated at the component boundary, so the value is always one of the closed sets below (anything unexpected is coerced to unknown / network-error).

error.code — recording could not start:

dropped.code — clip recorded but not stored:

<script setup lang="ts">
import { AudioRecorder } from "@a4anthony/proctorkit-vue";
import type {
  MediaClipErrorPayload,
  MediaClipDroppedPayload,
} from "@a4anthony/proctorkit-vue";

// Recording could not start.
function onError({ code, message }: MediaClipErrorPayload) {
  switch (code) {
    case "permission-denied":
      notify("Microphone is blocked. Enable it, then press Record."); break;
    case "no-device":
      notify("No microphone found. Plug one in and try again."); break;
    case "device-in-use":
      notify("Your mic is in use by another app. Close it and retry."); break;
    case "unsupported":
      notify("This browser can't record. Use a recent Chrome/Edge/Safari over HTTPS."); break;
    default:
      notify(`Couldn't start recording: ${message}`);
  }
}

// Clip recorded but was not stored.
function onDropped({ code }: MediaClipDroppedPayload) {
  if (code === "rejected") {
    // 4xx — auth / quota / origin. Retrying won't help.
    notify("Your answer was refused by the server. Please contact your proctor.");
  } else {
    // empty-recording / server-error / network-error — retry is worth offering.
    notify("Your answer wasn't saved. Please record again.");
  }
}
</script>

<template>
  <AudioRecorder :client="client" @error="onError" @dropped="onDropped" />
</template>

The code unions MediaClipErrorCode / MediaClipDropCode are exported for exhaustive handling. In standalone mode there is no server upload, so the only dropped code that can occur is empty-recording.

VideoRecorder props

VideoRecorder emits the same started / stopped / uploaded / dropped / error events as AudioRecorder, with kind: "video" in clip payloads. The sendClip mirror and clip-mirror-failed event are currently available on AudioRecorder only.

playAudioFile() plays a URL-backed audio prompt and emits audio-playback.started, audio-playback.paused, audio-playback.stopped, audio-playback.ended, or audio-playback.error. When a selected speaker/headphone is configured, output routing also emits audio-playback.sink-applied, audio-playback.sink-unsupported, or audio-playback.sink-failed. If the selected output disappears during playback, the SDK emits audio-playback.sink-disconnected and attempts to reroute the same audio element to the system default output. Event payloads remove query strings and hash fragments from the URL, so signed audio links are not written into the timeline.

function ListeningQuestion({ client }: { client: ProctoringClient }) {
  const player = useRef<AudioFilePlaybackHandle | null>(null);

  async function playPrompt() {
    player.current = client.playAudioFile({
      url: "https://cdn.example.com/prompts/q5.mp3?signature=...",
      label: "Question 5 listening audio",
      onEnded: () => markPromptListened(),
      onError: (_error) => showPlaybackError(),
    });
  }

  function stopPrompt() {
    player.current?.stop();
  }

  return (
    <div>
      <button type="button" onClick={playPrompt}>Play prompt</button>
      <button type="button" onClick={stopPrompt}>Stop</button>
    </div>
  );
}

If you render your own native controls, pass the existing <audio> element and disable autoplay:

client.playAudioFile({
  url: question.audioUrl,
  label: question.audioLabel,
  element: audioRef.current!,
  autoplay: false,
  sinkId: selectedSpeakerId,
});

playVideoFile() is the video twin of playAudioFile(): it plays a URL-backed video prompt and emits video-playback.started, video-playback.paused, video-playback.stopped, video-playback.ended, or video-playback.error. The video's audio track routes through the same speaker/headphone selection as audio prompts, emitting the matching video-playback.sink-* events. Payload URLs are stripped of query strings and hash fragments, so signed video links are not written into the timeline.

On top of the shared options, video adds poster, muted, and playsInline. Each is applied only when set, so a host-supplied <video> element keeps its own configuration; playsInline defaults to true for elements the SDK creates so iOS Safari keeps playback inline.

const handle = client.playVideoFile({
  url: "https://cdn.example.com/prompts/q7.mp4?signature=...",
  label: "Question 7 viewing prompt",
  poster: question.posterUrl,
  autoplay: false,
  onEnded: () => markPromptWatched(),
  onError: (_error) => showPlaybackError(),
});

// Later, from a candidate gesture:
await handle.play();

recordAudioClip() records microphone audio, uploads to the audio-clips endpoint, and emits audio-clip.started, audio-clip.stopped, and audio-clip.uploaded or audio-clip.dropped. The default safety cap is 2 minutes; pass maxDurationMs to make the limit explicit in your UI.

import type { ProctoringClient, VideoClipHandle } from "@a4anthony/proctorkit-sdk";
import { useRef, useState } from "react";

function SpeakingQuestion({ client }: { client: ProctoringClient }) {
  const activeClip = useRef<VideoClipHandle | null>(null);
  const [recording, setRecording] = useState(false);
  const [answerClip, setAnswerClip] = useState<number | null>(null);
  const [uploadError, setUploadError] = useState<string | null>(null);

  async function startRecording() {
    setUploadError(null);
    activeClip.current = await client.recordAudioClip({
      maxDurationMs: 120_000,
      onUploaded: (clipNumber, _byteSize, durationMs) => {
        setAnswerClip(clipNumber);
        console.info("Audio answer uploaded", { clipNumber, durationMs });
      },
      onDropped: (_clipNumber, reason) => {
        setUploadError(reason);
      },
    });
    setRecording(true);
  }

  async function stopRecording() {
    const clip = activeClip.current;
    if (!clip) return;
    await clip.stop();
    activeClip.current = null;
    setRecording(false);
  }

  return (
    <div>
      <button type="button" onClick={recording ? stopRecording : startRecording}>
        {recording ? "Stop" : "Record answer"}
      </button>
      <button type="button" disabled={answerClip === null || uploadError !== null}>
        Save answer
      </button>
    </div>
  );
}

recordVideoClip() records a bounded video answer and uploads it when the returned handle is stopped. It can use a stream you pass in, reuse the SDK webcam observer's camera stream, or request a fresh camera/microphone stream. When it must request media itself, call it directly from the candidate's button click so the browser permission prompt has user activation.

const videoClip = await client.recordVideoClip({
  maxDurationMs: 120_000,
  audio: true,
  videoBitrate: 1_500_000,
  onUploaded: (clipNumber, byteSize, durationMs) => {
    saveQuestionAnswer({
      questionId: "q_video_1",
      mediaKind: "video",
      clipNumber,
      byteSize,
      durationMs,
    });
  },
  onDropped: (_clipNumber, reason) => {
    showRecordingError(reason);
  },
});

// Candidate clicks "Done".
await videoClip.stop();

A retake should be treated as a new clip, not as an overwrite. Previous clips remain in the session evidence trail, while your assessment app decides which clipNumber is the submitted answer for that question.

let acceptedClipNumber: number | null = null;

async function recordAttempt(questionId: string) {
  const clip = await client.recordVideoClip({
    maxDurationMs: 120_000,
    onUploaded: (clipNumber) => {
      acceptedClipNumber = clipNumber;
      saveQuestionAnswer({ questionId, clipNumber });
    },
  });

  return clip;
}

// Retake flow:
// 1. Stop the current clip.
// 2. Let the candidate preview or discard it in your UI.
// 3. Start a new clip and store the new accepted clipNumber.
// The old clip stays visible to reviewers as evidence.

If your assessment app already owns the recorder and preview/retake UI, send the final video blob through uploadVideoClip(). It lands in the same dashboard surface as recordVideoClip() and emits the same uploaded/dropped timeline events.

const handle = await client.uploadVideoClip(recordedBlob, {
  durationMs: measuredDurationMs,
  onUploaded: (clipNumber, byteSize, durationMs) => {
    saveQuestionAnswer({
      questionId: "q_video_2",
      mediaKind: "video",
      clipNumber,
      byteSize,
      durationMs,
    });
  },
  onDropped: (_clipNumber, reason) => {
    showRecordingError(reason);
  },
});

console.info("Uploaded video answer", handle.clipNumber);

The Vue package also exports presentational building blocks for custom screens that sit around the first-party wizard or media controls. They are scoped to .pct-system-check and use the same CSS variables as the wizard.

import {
  ProctoringAlert,
  ProctoringSelect,
} from "@a4anthony/proctorkit-vue";

ProctoringAlert

Renders an inline message box with an optional tone icon, title, description, body slot, and dismiss action.

Use the default slot for richer content instead of description.

ProctoringSelect

A styled native <select> that suppresses the browser arrow and draws a consistent chevron. Keyboard and screen-reader behaviour remains native. Pass <option> children as usual. Layout attributes such as class and style land on the wrapper; form and accessibility attributes such as id, disabled, and aria-* pass through to the native element.

ProctoredTextarea is a drop-in textarea for writing questions that captures how an answer was produced — paste, typing dynamics, content checkpoints, focus, and writing-assistant footprints — alongside the answer text. Fully proctored with no config; props only disable signals or enable enforcement.

Two destinations, two owners. The answer text is yours — it's v-model'd in your app and saved through a saveAnswer function you provide (the SDK never writes to your database). The integrity signals flow to the proctoring server automatically and power the dashboard's Writing tab. The field shows Saving… → Saved ✓ around your save, like the recorder's Uploaded ✓.

<script setup lang="ts">
import { ProctoredTextarea } from "@a4anthony/proctorkit-vue";
import type { SaveAnswerFn } from "@a4anthony/proctorkit-vue";

const saveAnswer: SaveAnswerFn = async ({ text, questionId, signal }) => {
  const res = await fetch("https://api.example.com/answers", {
    method: "POST",
    body: JSON.stringify({ questionId, text }),
    signal,
  });
  if (!res.ok) throw new Error(`http_${res.status}`); // throw = save failed
};
</script>

<template>
  <ProctoredTextarea
    v-model="answer"
    question-id="q1"
    :save-answer="saveAnswer"
    @saved="onSaved"
    @save-failed="onSaveFailed"
  />
</template>

Signal and autosave props default on; the in-progress answer autosaves to localStorage and survives a refresh. In a sandboxed iframe (where local storage is denied) set persistAnswer so checkpoints carry the answer to the server. The writing-assistant detector (Grammarly etc.) records a footprint, not a guarantee, and is never blocked.

Exposed via a template ref: submit({ metMinimum }) (fires submitted, forwards your word/char-limit result) and dismissKeyboard(). The component also sets anti-assistant attributes (data-gramm="false", translate="no") on its textarea.

App keys (prefix pk_live_) are public — they ship in your candidate's browser. They are tied to an organisation, and the server tags every incoming event with that organisation.

The full secret is shown only once at creation time. Store it in your password manager or a 1Password vault. The dashboard always shows the prefix only, after creation.

Each key has a per-origin allow-list. When origins are configured, public SDK requests from any other origin are rejected with 403. Use * only for local demos, or leave the list empty when you intentionally accept every deployed origin for that key.

# In Settings → Keys → edit
allowedOrigins: ["https://exam.acme-uni.edu", "https://staging.exam.acme-uni.edu"]

Revocation is immediate for public SDK traffic. The moment you click "Revoke", the next request using that app key is rejected. Rotate by creating a replacement key, switching your test runner to the new value, confirming events land, then revoking the old key.

Webhooks push session lifecycle events from the proctor server into your platform. Configure a destination URL in Settings → Webhooks and pick the events you care about — your endpoint receives a signed JSON POST whenever one fires.

Each delivery is signed with HMAC-SHA256 over {timestamp}.{body}. The verifier ships in the SDK so you don't need to roll your own.

Seven event types are deliverable. Every payload shares the envelope below; the data field carries the event-specific fields.

{
  "type": "session.ended",
  "emittedAt": "2026-05-26T10:32:18.014Z",
  "data": { "sessionId": "sess_abc123", "reason": "stopped" }
}

Every POST carries three identification headers:

• X-Proctoring-Signature — t=<unix>,v1=<hex> where hex is HMAC-SHA256(secret, "{t}.{body}").
• X-Proctoring-Event — the event type, mirroring the body's type field.
• Idempotency-Key — stable across retries. Use it to dedupe in your handler.

Use the SDK helper to verify — it's constant-time and rejects stale timestamps (default tolerance 5 minutes).

import { verifyWebhookSignature } from "@a4anthony/proctorkit-sdk";

const ok = await verifyWebhookSignature({
  body: rawBodyString,
  header: req.headers["x-proctoring-signature"] ?? "",
  secret: process.env.PROCTOR_WEBHOOK_SECRET,
});
if (!ok) {
  return res.status(401).end();
}

Non-2xx responses (or network errors) re-enqueue the delivery at the next backoff step. The schedule:

Replay window: the signed timestamp must be within 5 minutes of your server's clock. Reject older signatures even if they verify — they may be captured replays.

Express:

import express from "express";
import { verifyWebhookSignature } from "@a4anthony/proctorkit-sdk";

const app = express();

app.post(
  "/webhooks/proctor",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const body = req.body.toString("utf8");
    const ok = await verifyWebhookSignature({
      body,
      header: (req.header("x-proctoring-signature") ?? ""),
      secret: process.env.PROCTOR_WEBHOOK_SECRET,
    });
    if (!ok) return res.status(401).end();

    const event = JSON.parse(body);
    // event.type, event.data.sessionId, event.emittedAt
    res.status(200).end();
  },
);

Next.js (App Router):

// app/api/webhooks/proctor/route.ts
import { verifyWebhookSignature } from "@a4anthony/proctorkit-sdk";

export async function POST(req: Request) {
  const body = await req.text();
  const ok = await verifyWebhookSignature({
    body,
    header: req.headers.get("x-proctoring-signature") ?? "",
    secret: process.env.PROCTOR_WEBHOOK_SECRET,
  });
  if (!ok) return new Response("unauthorized", { status: 401 });

  const event = JSON.parse(body);
  // event.type, event.data.sessionId, event.emittedAt
  return new Response("ok", { status: 200 });
}

Your app key has two halves, like Stripe. The publishable pk_… goes in the candidate's browser (SDK config); the secret sk_… goes only in your backend and authorizes this API. The secret can read and change your data, so it must never reach the browser — a candidate who had it could reset their own exam.

Issue one in Settings → Keys → Issue API secret. The full value is shown once — copy it into your backend secrets. Only a hash is stored; if you lose it, re-issue (the old one stops working).

Send the secret as a Bearer token. Responses use a stable envelope.

curl https://api.example.com/v1/sessions/sess_123 \
  -H "Authorization: Bearer sk_live_…"

# success → { "data": … }
# failure → { "error": "…" }  (with the matching HTTP status)

You issue a correlationId per exam attempt and pass it to the SDK. The system may create several sessions under one correlationId — one per attempt (a retake, a recovered abandon, a reset). So a correlationId is the attempt group (what your LMS knows); a sessionId is one attempt (what webhooks hand you). The API is correlationId-first, with sessions underneath — look up either way.

Did my candidate pass their latest attempt?

curl https://api.example.com/v1/attempts/exam-attempt-123/latest \
  -H "Authorization: Bearer sk_live_…"

{
  "data": {
    "sessionId": "sess_…",
    "correlationId": "exam-attempt-123",
    "status": "ended",
    "attemptNumber": 1,
    "preflight": { "passed": true, "requiresReverification": false },
    "analysis": { "webcam": "completed", "screen": "completed", "photo": "completed" }
  }
}

Let them retake, then pull the report PDF:

curl -X POST https://api.example.com/v1/attempts/exam-attempt-123/reset-latest \
  -H "Authorization: Bearer sk_live_…"

curl https://api.example.com/v1/sessions/sess_…/report \
  -H "Authorization: Bearer sk_live_…" -o report.pdf

Demo tests lets an owner or admin create client-demo assessments without hardcoding content in the SDK host. A demo test can include written, multiple-choice, listening multiple-choice, speaking, and video questions. Publishing a test produces a candidate link that the SDK host loads by testId.

http://127.0.0.1:5733/?appId=pk_demo_seed01&testId=customer-success-readiness&correlationId=client-demo-001

The local :5733 candidate host is a Vue app that uses ProctoredAssessment. It resolves the internal attempt, runs or skips preflight from the saved policy, then renders the backend question list one question at a time. The core SDK stays framework-neutral; Vue is only the demo host and customer wrapper layer.

Candidate links created from demo tests resolve to normal internal proctoring sessions, but those sessions are marked demo. The Sessions page defaults to live sessions only; use the session-source filter to inspect demo runs or include both live and demo rows.

The builder also owns the demo assessment's proctoring policy. The policy is saved on the backend and returned by the public SDK assessment endpoint. Candidate-link query params can choose appId, testId, correlationId, and candidate identity, but they cannot turn required preflight or runtime proctoring checks off.

Listening questions are multiple-choice questions with an attached audioUrl in the question config. The SDK host plays that URL through client.playAudioFile(), so prompt playback is visible in the session timeline without storing signed URL query strings. The seeded demo uses local MP3 files under /audio/.

Speaking questions call client.recordAudioClip(). Video questions call client.recordVideoClip() with the question's configured max duration. These answer clips are separate from passive webcam or screen-share proctoring recordings.

The sessions table shows the stored session status plus a recent activity state derived from SDK heartbeats and incoming events. Demo sessions show a Demo badge when included in the list, are excluded from live usage counters, and are automatically purged after 24 hours.

The client-owned correlationId stays stable across retries. The backend maps that value to an internal sess_... id for each attempt. If the candidate returns after the inactivity window, the old internal attempt is marked abandoned and the same client correlation id resolves to the next attempt number.

Session detail shows the internal session id, attempt number, app-key prefix, preflight state, and Last active. When a retry chain has multiple attempts, the detail page can show the active attempt or merge all attempts into one timeline.

The score is a transparent formula — no vendor heuristic. Each flag category contributes a fixed penalty (focus 3, clipboard 4, face 5, exit 8) and the score is clamped to 0-100. Tune the formula in your self-hosted deploy if you want.

Use the chips above the timeline to filter by category, or type into the search box to filter by event kind. Every event has a permalink: click the event id to share a deep link with a teammate.

Settings → Billing shows the live V1 usage model: sessions this month, event volume, media/storage usage, monthly event quota, monthly media quota, and SDK rate limit. These counters are tied to the same usage guards used by public SDK ingest and count only live sessions. Demo assessment runs stay available for review for 24 hours but do not consume monthly event or media quota.

Settings → Webhooks lets an organisation create endpoints, select subscribed lifecycle events, pause or resume delivery, and inspect delivery attempts. The endpoint detail page shows status, attempt number, response code, response snippet, next retry time, and resend controls.

The sessions list can export the filtered result set as CSV. A session detail page can export the event timeline as CSV, download a clean PDF report, or download a PDF report that includes internal reviewer notes.

pnpm preview builds the workspace, starts Docker, applies migrations, clears the preview host ports, starts the built server/worker/dashboard, starts Vue Storybook on :6007, and serves the Vue SDK demo host on :5733. After a successful build, use pnpm start:built to restart the same built stack without rebuilding.

pnpm preview

# after a successful build
pnpm start:built

# skip Vue SDK demo host
pnpm preview --no-sdk-host

# skip Storybook
pnpm preview --no-storybook

# inspect port conflicts manually instead of clearing them
pnpm preview --no-clear-ports

The V1 smoke test verifies the surfaces used in a client demo: API health, dashboard login, overview, sessions, session detail with Last active, billing quotas, app-key create/update/rotate/revoke, SDK demo launch, preflight skip, Begin test, question progression, and SDK ingest.

pnpm smoke:v1

# optional overrides
DASHBOARD_URL=http://127.0.0.1:3000 \
API_URL=http://127.0.0.1:3001 \
SDK_HOST_URL=http://127.0.0.1:5733 \
SMOKE_APP_ID=pk_demo_seed01 \
pnpm smoke:v1

The seeded demo account is demo@proctor.app / demo1234. The seeded SDK app key is pk_demo_seed01. Open the Vue SDK demo host with the seeded demo test and a client-owned correlation id to show realistic retries.

http://127.0.0.1:5733/?appId=pk_demo_seed01&testId=customer-success-readiness&correlationId=client-demo-001&email=demo.candidate@example.com&name=Demo%20Candidate

The seeded demo assessment is published from dashboard-owned seed data and has 10 questions: written, multiple-choice, speaking, and video. For client-specific demos, create or edit a test in Demo tests, choose the proctoring preset and advanced toggles, publish, then copy the candidate link. The fuller walkthrough lives in docs/V1_CLIENT_DEMO_RUNBOOK.md.