Перейти к основному содержанию
Отчёт Проверки электронной почты содержит полный результат OTP-проверки по email: кому было отправлено сообщение, является ли адрес одноразовым или недоставляемым, фигурирует ли он в известных утечках данных, сколько попыток потребовалось пользователю, а также любые межсессионные совпадения с вашим списком блокировки или другими одобренными пользователями. На этой странице описана структура JSON, возвращаемая endpoint решения, что позволяет анализировать результаты OTP, наличие адреса в утечках и флаги риска для каждого проверенного адреса.
Didit email verification report showing OTP outcome, breach data and risk flags

Обзор

Отчёт по email формируется каждый раз, когда узел сценария выполняет функцию «Проверка электронной почты». Каждый отчёт представляет одну OTP-проверку для одного адреса и содержит:
  • Проверенный адрес email.
  • Логические флаги риска (is_breached, is_disposable, is_undeliverable) и подтверждающий массив breaches[], полученный из базы данных об утечках.
  • Количество попыток отправки OTP (verification_attempts) и временную метку одобрения.
  • Хронологический журнал lifecycle[] для каждой отправки, повторной попытки и попытки проверки кода.
  • Массив matches[], отображающий тот же адрес в других одобренных проверках электронной почты или в вашем списке блокировки.
  • Массив warnings[] — события риска, зафиксированные в ходе верификации (см. раздел Предупреждения Проверки электронной почты).
  • Идентификатор node_id, указывающий, какой узел графа сценария сформировал отчёт (только для сессий V3).
В размещённых сессиях сценария OTP-проверка выполняется внутри интерфейса верификации Didit — вы только считываете результат из payload решения. Для межсерверной OTP-проверки без размещённого сценария используйте отдельный Email API: POST /v3/email/send/ доставляет код, а POST /v3/email/check/ проверяет ввод пользователя; завершённые отдельные верификации возвращаются в той же структуре отчёта. По умолчанию в размещённых сессиях для пользователя установлено ограничение в 2 неверные попытки ввода кода (email_max_check_attempts) и 2 отправки OTP — начальная отправка плюс одна повторная (email_max_retries), настраиваемое для каждого узла сценария. Превышение любого из этих лимитов завершает шаг со статусом Declined и причиной EMAIL_CODE_ATTEMPTS_EXCEEDED.

Где он появляется в ответах API

Endpoint решения (GET /v3/session/{sessionId}/decision/) возвращает отчёты по email в массиве под ключом во множественном числе email_verifications. Массив содержит по одной записи для каждого узла Проверки электронной почты в графе сценария — обычно одну, но сценарии с усиленной проверкой могут создавать несколько.
Значение null означает, что шаг Проверки электронной почты ещё не выполнялся. Перебирайте элементы массива (вместо чтения только email_verifications[0]), если ваш сценарий может запрашивать более одного адреса электронной почты.

Схема

Каноническая схема с построчным описанием полей находится на странице Модели данных.
Недоставляемый адрес — неверный синтаксис, несуществующий домен, отсутствие MX-записей или сбой доставки OTP — переводит шаг в статус Declined с предупреждением об автоматическом отклонении UNDELIVERABLE_EMAIL_DETECTED. Единственное исключение: если пользователь ввёл адрес самостоятельно (он не был предварительно заполнен при создании сессии), неудачная отправка возвращает встроенную ошибку, позволяя повторить попытку с другим адресом вместо немедленного отклонения.

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

Типы событий жизненного цикла

Массив lifecycle[] отсортирован в хронологическом порядке. Каждое событие содержит type, timestamp, details и тарифицируемую комиссию fee (когда применимо): Содержимое поля details зависит от семейства событий:
  • События отправки (EMAIL_VERIFICATION_MESSAGE_SENT, EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) — { status, reason }. Поле status принимает значения Success, Retry или Undeliverable; reason имеет значение null, если отправка завершилась успешно; при ошибке он содержит email_can_not_be_delivered или unknown для нераспознанных устаревших значений.
  • События проверки (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } со status Approved, Failed, Expired or Not Found или Declined.
  • События финального статуса — null, кроме EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, которые содержат { "reason": "<risk code>" } (например, UNDELIVERABLE_EMAIL_DETECTED).
Отправки со status Success или Undeliverable фиксируют комиссию $0.02 за Проверку электронной почты; повторные отправки Retry, события проверки и события статуса всегда содержат fee: 0.

Совпадения между сессиями

В matches[] фиксируются совпадения одного и того же адреса в ранее одобренных верификациях электронной почты в рамках того же приложения — включая сессии KYC, KYB и автономного API — а также срабатывания списков блокировки, настроенных через списки Management API. Верификации с тем же vendor_data, что и текущая сессия, исключаются (один и тот же конечный пользователь не сопоставляется сам с собой), массив ограничен 5 записями, отсортированными от старых к новым. Если адрес находится в вашем списке блокировки, но ни одна из найденных сессий не заблокирована, в начало массива добавляется синтетическая запись с source: "list_entry" (все поля сессии null).

Примеры

Одобрено — корректный OTP с одним информационным срабатыванием

Отклонено — недоставляемый адрес

Предварительно заполненный адрес, не прошедший проверку синтаксиса или DNS (MX) — либо письмо с OTP, которое не может быть доставлено — сразу получает статус Declined. События проверки кода отсутствуют, так как код не был доставлен пользователю.

Отклонено — одноразовый почтовый ящик, внесённый в список блокировки

Пользователь ввёл OTP, но адрес совпал с вашим списком блокировки электронной почты (автоотклонение). Также выставлен флаг одноразовой почты — здесь на уровне information, поскольку для disposable_email_action оставлено значение по умолчанию NO_ACTION.

Связанные разделы

Последнее изменение 7 ноября 2026 г.