Прокторинг: backend и frontend SDK

Три вещи от менеджера интеграции: API-ключ организации, адреса стенда (API, CDN, приложение и отчёты, медиа-сервер, ИИ-отчёты) и подтверждённый состав полей студента. Адреса впишите в разделе «Адреса стенда» — все примеры на этой странице подставят их автоматически. API-ключ подставляется отдельно: введите его в поле api_token в шапке страницы, и он появится в примерах вместо YOUR_API_TOKEN.

Один. POST /api/external-session/assignment.json создаёт задание, регистрирует студента и возвращает токен. Запрос идемпотентный по assignment.external_id и student.external_id — повторный вызов обновляет данные, а не плодит дубликаты. Токены можно подготовить заранее, пачкой на всех участников, и сохранить у себя.

Ключ живёт только на вашем backend и не должен попадать в JS-бандл, конфиг фронтенда, репозиторий и логи запросов. Создавать сессию из браузера нельзя: API-ключ даёт доступ к данным всей организации. Во фронтенд уходит исключительно external_session.token, привязанный к конкретной попытке. Передаётся ключ либо параметром ?api_token=YOUR_API_TOKEN, либо заголовком X-Authorization — см. «Создание экзамена».

token — токен внешней сессии, рекомендуемый режим для внешних интеграций: SDK сам определит экзамен. access_token — Bearer-токен пользователя для внутренних интеграций, и он требует дополнительно передать assignment. Если не передано ни то, ни другое, initialize выбросит Access Token is required.

В режиме assignment.application: browser — нет, всё работает в обычном браузере. Режимы desktop (защищённое приложение) и tray (фоновый агент) требуют отдельного дистрибутива — состав и порядок выдачи уточняйте у менеджера интеграции.

Да. Песочница возвращает заранее подготовленные ответы (в том числе 401 и 422) без обращения к сети, а конструктор собирает готовое тело запроса. Реальный стенд для тестов выдаёт менеджер.

Идентификатор — обязательное поле student.external_id, ваш идентификатор пользователя. Именно по нему работает идемпотентность: повторный запрос обновляет того же студента, а не заводит нового.

Персональные данные (имя, фамилия, e-mail) передаются рядом с ним. Примеры запроса на этой странице собирают их плоскими полями объекта student:

{ "external_id": "user-10254", "firstname": "Иван", "lastname": "Иванов", "email": "ivan.ivanov@example.com" }

При создании сессии — обязательный student.external_id и персональные поля (имя, фамилия, e-mail), которые нужны для отчёта; см. вопрос выше.

Передайте session_data.external_id при создании сессии — он вернётся в webhook типа Default полем assignment_attempt_external_id.

На медиа-сервере платформы, по WebRTC, по мере записи. При включённой локальной записи после finish() открывается окно догрузки файлов — вкладку до конца загрузки закрывать нельзя, предупредите об этом студента в своём интерфейсе.

Двумя способами, они дополняют друг друга:

• report_url — готовая страница с видеозаписями, таймлайном событий и скриншотами. Приходит в ответе на создание сессии; сохраните её у себя сразу.
• Webhook — платформа сама сообщит вашему серверу о старте и завершении, опрашивать API не нужно (Webhooks).

Отчёты живут на стороне платформы: report_url открывается по сохранённой ссылке, адрес приложения отчётов входит в адреса стенда, которые выдают при подключении.

Только повторным запросом создания сессии. Сохраняйте report_url в своей БД сразу, вместе с attempt.id, привязанными к попытке студента.

Через webhooks: assignment.settings.webhook.start_url и finish_url. Туда же можно добавить свои поля в тело (post), заголовки (headers) и параметры строки запроса (query) — например авторизацию вашего эндпоинта.

Да, report_url открывается и отдельной вкладкой, и в <iframe>: это готовая страница с видеозаписями, таймлайном событий и скриншотами.

Базовый сценарий — асинхронный: платформа пишет попытку, детекторы фиксируют события, по завершении доступны отчёт и ИИ-оценка риска (low / medium / high / critical) с текстовой сводкой и интервалами для просмотра. Нужен ли ручной разбор — решаете вы по уровню риска. Синхронный (живой) прокторинг эта документация не описывает — о нём разговаривайте с менеджером интеграции.

Да. Без защищённого соединения браузер не отдаёт getUserMedia и getDisplayMedia — камера, микрофон и демонстрация экрана не запустятся.

Параметр browser_type ограничивает, в каком браузере можно сдавать: * (любой), chrome, edge, opera, yandex. Это настройка допуска, а не матрица совместимости — минимальные версии браузеров в документации не зафиксированы, уточняйте их у менеджера интеграции. Проверьте интеграцию именно в тех браузерах, которые разрешаете студентам, — это отдельный пункт предстартового чек-листа.

Домены CDN, API, медиа-сервера, приложения и ИИ-отчётов (см. «Куда обращается SDK»), а также WebRTC (STUN/TURN) и разрешения на камеру, микрофон и захват экрана в браузере пользователя.

Нет. В загрузчике app.js зашит адрес основного бандла, подставленный при сборке стенда: бандл всегда загрузится с того же домена, откуда взят загрузчик. Смешивать стенды нельзя.

Нет — только то, что отличается от значений по умолчанию, остальное подставится само. Конструктор в режиме «Только изменённое» собирает минимальное тело запроса.

Повторным POST с тем же assignment.external_id: запрос идемпотентный и обновит настройки, а не создаст второй экзамен.

Нужны обе части: content_protect: true в настройках экзамена на backend и protector.match с селектором защищаемого блока в initialize. Плюс ограничения: защитить можно только один элемент, демонстрация экрана возможна лишь в режиме записи окна, а на части устройств защита не активируется — предусмотрите запасной сценарий в onError.