Skip to content

Meeting Liveness Bot — Overview

The Meeting Liveness Bot joins video calls on your behalf and runs real-time liveness detection on each participant using the Moveris API.

In plain terms

When someone joins a video interview, a bot enters the call like a participant. It watches each person's camera feed, sends frames to Moveris for analysis, and reports whether each participant appears live or fake. Your backend receives results through webhooks; an optional read-only link lets a human observer watch verdicts in real time.

What It Does

Automated join

Provide a Google Meet, Zoom, or Teams URL—the bot enters the call through Moveris’s meeting provider integration.

Per-participant checks

Each person on camera is analyzed independently with their own verdict.

Webhook delivery

Pass/fail results POST to your server after each analysis completes.

Interviewer view

Optional token link for a human observer—no login, live SSE updates.

Camera re-scan

Detects camera off/on and re-analyzes after a configurable quiet period.

Targeted scanning

Scan only named participants (and skip interviewers) using fuzzy + optional LLM name matching.

V2, V3, V3.1, and V3.1.1 models

Same model aliases as the REST API—including the latest mixed-*-v3_1_1 models.

Slack alerts (optional)

Post liveness verdicts to Slack when Moveris enables alerts on your bot deployment.

Frame quality gating

Rejects blurry, dark, or poorly framed frames before analysis and streams frame-quality-rejected over SSE for live guidance.

Background segmentation (optional)

Replaces participant backgrounds with neutral grey before fast-check when enabled for the session.

Architecture at a Glance

flowchart TB
    BE[Your backend] -->|POST /api/sessions| BOT[Meeting Liveness Bot]
    BOT --> REC[Meeting provider]
    REC -->|WebSocket frames| BOT
    BOT -->|fast-check| API[Moveris API]
    API -->|liveness.result webhook| BE
    BOT -->|SSE optional| UI[Interviewer UI]
    BE -.->|share interview link| UI

For the full pipeline (frame buffering, correlation IDs, auth paths), see How It Works.

Integration Paths

flowchart LR
    subgraph Prod["Production integration"]
        M2M[M2M API key] --> S[POST /api/sessions]
        S --> W[Webhook receiver]
    end

    subgraph Optional["Optional"]
        IV[Interview token link]
        OAUTH[Browser UI + Google OAuth]
    end

    Prod --> Optional
Path Who uses it Auth
Machine-to-machine (M2M) Your backend before/during a meeting Authorization: Bearer sk-bot-<key>
Browser UI Internal operators scheduling sessions Google OAuth (optional)
Interviewer view Human observer during the call Signed interviewToken in URL

Most production integrations use M2M + webhooks, with the interviewer link when a human needs a live dashboard.

Supported Meeting Platforms

Platform Example URL format
Google Meet https://meet.google.com/xxx-xxxx-xxx
Zoom https://zoom.us/j/123456789
Microsoft Teams https://teams.microsoft.com/l/meetup-join/...

Models

The bot passes your model field to POST /api/v1/fast-check. All mixed aliases from the REST API are supported.

Quick picker

If you need… Start with
Lowest latency in a live call mixed-10-v3_1_1 or mixed-10-v2
Best default balance mixed-30-v3_1_1 or mixed-30-v2
Highest scrutiny mixed-60-v3_1_1, mixed-90-v3_1_1, or mixed-60-v2

By generation

Mixed V2 — mixed-10-v2 through mixed-120-v2
Model Frames
mixed-10-v2 10
mixed-30-v2 30
mixed-60-v2 60
mixed-90-v2 90
mixed-120-v2 120
Mixed V3 (mixed-10-v3, mixed-30-v3, mixed-60-v3)
Model Frames
mixed-10-v3 10
mixed-30-v3 30
mixed-60-v3 60
Mixed V3.1 (mixed-10-v3_1 through mixed-90-v3_1)
Model Frames
mixed-10-v3_1 10
mixed-30-v3_1 30
mixed-60-v3_1 60
mixed-90-v3_1 90
Mixed V3.1.1 — latest generation (recommended for new integrations)
Model Frames
mixed-10-v3_1_1 10
mixed-30-v3_1_1 30
mixed-60-v3_1_1 60
mixed-90-v3_1_1 90
mixed-120-v3_1_1 120

See Models Overview and Model Versioning & Frames.