Status lifecycle
scheduled
Session row created. AI hasn’t joined yet. The candidate can join via the
join_url from the invite at any time.in_progress
Candidate joined and the AI is actively interviewing. Transcript +
authenticity signals stream into the session record live.
completed
Interview finished naturally — the AI delivered the closing line and
ended the call. Scorecard ready within 2 minutes.
failed
Candidate disconnected mid-interview, or a tech failure interrupted the
session. Partial transcript may still be available; no scorecard.
cancelled
Recruiter cancelled the session via the API or UI before the candidate
joined. No interview happened.
Status changes emit events
Every state transition fires a webhook. Configure your endpoint to receive them — see Webhooks for the payload shape + HMAC signing.| Transition | Event fired |
|---|---|
| Created (via API or UI) | session.created |
| Candidate joins | session.started |
| Completes naturally | session.completed |
| Fails / disconnects | session.failed |
| Cancelled by recruiter | session.cancelled |
| Scorecard finalized | session.scored (fires 30s–2min after completed) |
Reading a session
Re-runs and retries
Each session is immutable once it lands in a terminal state (completed / failed / cancelled). If you need another interview for
the same candidate — say after a technical failure — create a fresh
session. Sessions for the same (participant, stage) are independent
rows; the platform doesn’t try to “merge” or “supersede” them.
The Applications panel on each template’s detail page automatically
picks the latest session per stage when displaying the rolled-up
status, so retries surface immediately.
Multi-stage progression
Multi-stage templates auto-create a fresh session for the next stage when a candidate passes a stage. You don’t need to manually invoke this — the session-status mirror trigger handles it. A candidate’s full trajectory through a 3-stage template ends up as 3 sessions, one per stage, linked through the samecandidate_id. See
Templates for how stages chain together.
Session vs application
These are two different objects, easy to confuse:| Object | Purpose |
|---|---|
| Session | One conversation between AI and participant. Holds the transcript, scores, recording. |
Application (template_applications) | The relationship between a participant and a template. Tracks HR approval, scheduling status, and the latest session. Created by the public apply flow or by manually adding a participant to a template. |
template_applications, but the data shown (scores, transcripts, status)
comes from the latest session joined onto the application. They’re paired
1:N — one application can have many sessions over time (retries,
multi-stage progressions).