Перейти к основному содержанию
Отчёт по анкете содержит структурированную форму, показанную пользователю, пройденный им путь по условным ветвям и ответ на каждый видимый элемент. Он возвращается для каждого узла, поэтому сценарии с несколькими экземплярами (например, по одной анкете на каждого UBO) содержат по одной записи на каждый экземпляр.
Отчёт Didit по KYC-анкете, показывающий структурированные ответы, разделы и типы элементов

Обзор

Каждый ответ на анкету описывает:
  • Версию анкеты, которую видел пользователь (название, описание, языки, метаданные версии, разделы).
  • Видимые элементы на пути, который пользователь фактически прошёл по графу формы, — скрытые условной логикой элементы исключаются из ответа.
  • Ответ на каждый видимый интерактивный элемент в формате, соответствующем его element_type.
  • Единый статус для ответа в целом.
Элементы разметки преобразуются в структуру, а не заполняются ответами: каждый SECTION_HEADER становится границей раздела (его заголовок и описание становятся title/description раздела), а HEADING, PARAGRAPH и SEPARATOR остаются в items[] без ключа answer, чтобы отчёт сохранял ту же визуальную структуру, которую видел пользователь.

Где отображается

Отчёт по анкете возвращается в виде массива во множественном числе questionnaire_responses[] в GET /v3/session/{sessionId}/decision/ как для сессий KYC, так и для KYB, если выполнялась функция анкеты. Поле имеет значение null до тех пор, пока не будет запущен хотя бы один экземпляр анкеты. Каждая запись содержит node_id, благодаря чему сценарии с несколькими экземплярами могут однозначно определить, какой шаг графа её создал.

Формат элементов

Каноническую схему см. в разделе Ответ на анкету в справочнике моделей данных.
Элементы SECTION_HEADER никогда не появляются в items[] — они открывают новый раздел и задают его title и description.

Типы элементов

Видимый интерактивный элемент, на который пользователь так и не ответил, возвращается с "answer": null.

Условная видимость

Если анкета определяет граф (условную логику), включаются только элементы на пути, который пользователь фактически прошёл. Элемент, скрытый ветвью, по которой пользователь не пошёл, не появляется в sections[].items — даже если он есть в шаблоне. Разделы, в которых не осталось видимых элементов, полностью опускаются.

Значения статуса

Поле status на уровне ответа принимает одно из трёх значений. Внутри системы базовый статус (Approved или In Review, если сценарий принудительно требует ручной проверки) объединяется с любыми сработавшими пользовательскими правилами статуса в соответствии с единым для всей платформы порядком приоритета Declined > In Review > Approved; затем результат уровня анкеты Declined преобразуется в In Review, чтобы операторы вынесли окончательное решение в ходе проверки.

Предупреждения

Анкеты генерируют единственный код предупреждения, возникающий при совпадении ответа с пользовательским правилом статуса, настроенным на узле анкеты: Поле additional_data предупреждения содержит field, operator, rule_value, actual_value, target_status и score, если правило его определяет. Его log_type зависит от целевого статуса правила: error для Declined, warning для In Review и information в остальных случаях. В отличие от других функций, запись анкеты не содержит встроенный массив warnings[] — журналы сработавших правил записываются в сессии под feature: "QUESTIONNAIRE" и отображаются на экране проверки в Консоли (см. также список предупреждений функции «Верификация бизнеса (KYB)»; тот же код применяется к сессиям KYC).

Пример — анкета об источнике средств

Пример — не завершено

Когда пользователь дошёл до шага с анкетой, но ещё не отправил ответы, ответ возвращается со status: "Not Finished" и "answer": null для каждого видимого элемента. Сессия, которая так и не дошла до этого шага, вообще не создаёт записей — questionnaire_responses остаётся null, если ни одного экземпляра не существует.

Примечания

  • Срок действия URL файлов истекает. Записи в answer.files представляют собой предварительно подписанные URL (со сроком действия 4 часа по умолчанию). Повторно вызовите endpoint решения, когда вам понадобятся свежие URL.
  • Локализация. Элементы title, description, placeholder, варианты выбора label, а также title/description разделов возвращаются на английском языке, если анкета это поддерживает, в противном случае на языке, указанном в default_language анкеты. Значение value варианта выбора остаётся неизменным для всех языков, поэтому вы можете безопасно использовать его в бизнес-логике.
  • Поле элемента description представляет собой вспомогательный текст элемента. Любой элемент может содержать его, включая вопросы, и оно равно null, если текст не задан. У SEPARATOR его никогда не бывает.

Связанные материалы

Обзор анкет

Как создавать, версионировать и прикреплять анкеты к сценарию.

Модели данных — Ответ на анкету

Каноническая схема объекта с описанием каждого поля.

Получить сессию

Справочник по endpoint для payload решения V3.
Последнее изменение 7 ноября 2026 г.