Proctor

Quickstart

Create an organization, run one monitored session end to end, and read its evidence — the whole loop, in about fifteen minutes.

6 min read

This walks the complete loop once: an organization, an interviewer, a candidate, a monitored session, and the evidence it produced. Nothing here needs an integration or a line of code — the API comes later, on its own page.

The loop

  1. Sign in and land in your organization

    An organization is the tenant: its members, sessions, evidence and retention policy are scoped to it and never cross to another. Your invitation already placed you in one — the owner's invitation creates it, and every later invitation adds a member to it.

  2. Invite the person who will run the interview

    Users → Invite. Give them the interviewer role — enough to run and review sessions, not enough to change the organization's plan or retention. Roles are enforced in the API, so this is a real boundary rather than a hidden menu.

  3. Create a session

    Sessions → New session. Choose what is collected — everything starts off — and the form shows exactly what the candidate will be asked before you create it. The next screen gives you a single-use join link for the candidate. Nothing is captured yet, and nothing will be until they consent on their own machine.

  4. Or create it from your own code (optional)

    Integrating an ATS or your own system instead? Developers → API keys → New API key (shown once; use a sandbox key, sk_test_…, while you are finding your feet — its sessions never mix with live ones). One request creates the session and one more mints the candidate's link.

    Schedule one, and mint the candidate's link
    curl -X POST "$PROCTOR_BASE_URL/v1/api/sessions" \
  -H "Authorization: Bearer $PROCTOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"externalId":"my-first-session"}'

curl -X POST "$PROCTOR_BASE_URL/v1/api/sessions/<id>/join-links" \
  -H "Authorization: Bearer $PROCTOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"role":"candidate"}'

  5. Install the desktop app on the candidate's machine

    Send them the download page, or open it yourself on a second machine to play the part. Each installer's SHA-256 is published beside it; check it the first time. Publisher certificates for macOS and Windows are not in place yet, so macOS and Windows will warn that the publisher cannot be verified the first time the app is opened — compare the SHA-256 before you continue. Grant the OS permissions the app asks for — screen recording is the one that usually needs a restart of the app.

    Verify before installing (macOS)
    shasum -a 256 ~/Downloads/<file>.dmg
spctl --assess --type install --verbose ~/Downloads/<file>.dmg

  6. Open the join link and read the consent screen

    The app shows exactly what will be collected and asks the candidate to agree to it in these words: “I agree that this application will monitor only the information described below during this interview.” Nothing is captured before that record exists on the server — the event API refuses writes for a session without one, so this is enforced, not merely promised.

  7. Run the session

    Once consent is recorded the session goes live and a monitoring indicator stays visible for its whole duration: a banner in the app and an icon in the menu bar or tray. There is no hidden mode, and there is no way to configure one.

  8. End it, then read the evidence

    End the session from the portal or the app. Uploads finish in the background; the session page shows the timeline, screenshots, audio and transcript as each arrives, and the report page collects them with reviewer notes. What you will not find anywhere is a verdict — the product reports observations and a person draws the conclusion.

What a session always requires

Two scopes are the floor: a session cannot run without them, and the consent screen names both. Everything else — microphone, camera, the paired phone's side view, recognised screen text — is separately consented and separately gated by your organization's policy, off unless you turn it on.

  • screen_recording
  • running_interview_application_status

Where to go next

  • How it works — the agent, the server and the portal, and what crosses between them.
  • Privacy — the full list of what is and is not collected, scope by scope.
  • Authentication — API keys, the request envelope, rate limits, idempotency.
  • SDK quickstart — the same loop above, driven from Node.
NextHow it works