Langsung ke konten utama
Laporan Verifikasi Email mencatat hasil lengkap dari tantangan OTP email: kepada siapa pesan dikirim, apakah alamat tersebut sekali pakai atau tidak dapat menerima email, apakah alamat tersebut muncul dalam kebocoran data yang diketahui, berapa banyak percobaan yang dilakukan pengguna, dan setiap kecocokan lintas-sesi terhadap daftar blokir Anda atau pengguna lain yang telah disetujui. Halaman ini mendokumentasikan format JSON yang dikembalikan oleh endpoint keputusan sehingga Anda dapat mem-parsing hasil OTP, paparan kebocoran data, dan tanda risiko untuk setiap alamat yang diverifikasi.
Laporan verifikasi email Didit yang menampilkan hasil OTP, data kebocoran, dan tanda risiko

Ringkasan

Laporan email dibuat setiap kali node alur kerja menjalankan fitur Verifikasi Email. Setiap laporan merepresentasikan satu tantangan OTP terhadap satu alamat dan berisi:
  • Alamat email yang diverifikasi.
  • Tanda risiko boolean (is_breached, is_disposable, is_undeliverable) serta array pendukung breaches[] yang bersumber dari database intelijen kebocoran.
  • Jumlah percobaan pengiriman OTP (verification_attempts) dan stempel waktu persetujuan.
  • Log kronologis lifecycle[] dari setiap pengiriman, percobaan ulang, dan pemeriksaan kode.
  • Array matches[] yang memunculkan alamat yang sama pada verifikasi email lain yang disetujui atau daftar blokir Anda.
  • Array warnings[] — event risiko yang dikeluarkan selama verifikasi (lihat Peringatan Verifikasi Email).
  • Sebuah node_id yang mengidentifikasi node graf alur kerja mana yang menghasilkan laporan tersebut (khusus sesi V3).
Dalam sesi alur kerja yang di-hosting, tantangan OTP berjalan di dalam UI verifikasi Didit — Anda hanya membaca hasilnya dari payload keputusan. Untuk OTP server-ke-server tanpa alur yang di-hosting, gunakan Email API mandiri: POST /v3/email/send/ mengirimkan kode dan POST /v3/email/check/ memvalidasi entri pengguna; verifikasi mandiri yang telah selesai ditampilkan melalui format laporan yang sama. Sesi yang di-hosting membatasi pengguna hingga 2 kali entri kode yang salah (email_max_check_attempts) dan 2 kali pengiriman OTP — pengiriman awal ditambah satu kali kirim ulang (email_max_retries) secara default, yang dapat disesuaikan per node alur kerja. Melebihi salah satu batas tersebut akan menetapkan langkah sebagai Declined dengan EMAIL_CODE_ATTEMPTS_EXCEEDED.

Tempat kemunculannya dalam respons API

Endpoint keputusan (GET /v3/session/{sessionId}/decision/) mengembalikan laporan email dalam array dengan kunci jamak email_verifications. Array ini berisi satu entri per node Verifikasi Email dalam graf alur kerja — biasanya satu, tetapi alur peningkatan dapat menghasilkan beberapa entri.
Nilai null berarti belum ada langkah Verifikasi Email yang berjalan. Lakukan iterasi pada array (daripada hanya membaca email_verifications[0]) ketika alur kerja Anda dapat mengumpulkan lebih dari satu alamat email.

Skema

Skema kanonik per kolom terdapat di halaman Model data.
Alamat yang tidak dapat dijangkau — sintaks tidak valid, domain yang tidak ada, catatan MX yang hilang, atau pengiriman OTP yang gagal — menyelesaikan langkah sebagai Declined dengan peringatan penolakan otomatis UNDELIVERABLE_EMAIL_DETECTED. Satu-satunya pengecualian: ketika pengguna mengetik sendiri alamat tersebut (tidak diisi sebelumnya saat pembuatan sesi), pengiriman yang gagal disampaikan mengembalikan error inline sehingga mereka dapat mencoba lagi dengan alamat yang berbeda alih-alih langsung ditolak.

Nilai status

Jenis event siklus hidup

lifecycle[] diurutkan secara kronologis. Setiap event memiliki type, timestamp, details, dan fee yang dapat ditagih (jika berlaku): Payload details bergantung pada kelompok event:
  • Event pengiriman (EMAIL_VERIFICATION_MESSAGE_SENT, EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) — { status, reason }. status berupa Success, Retry, atau Undeliverable; reason bernilai null kecuali pengiriman gagal (email_can_not_be_delivered, atau unknown untuk nilai lama yang tidak dikenali).
  • Event pemeriksaan (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } dengan status Approved, Failed, Expired or Not Found, atau Declined.
  • Event status akhir — null, kecuali EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, yang memuat { "reason": "<risk code>" } (misalnya UNDELIVERABLE_EMAIL_DETECTED).
Pengiriman dengan status Success atau Undeliverable mencatat biaya Verifikasi Email sebesar $0.02; pengiriman Retry, event pemeriksaan, dan event status selalu memuat fee: 0.

Kecocokan lintas sesi

matches[] mencatat alamat yang sama pada verifikasi email yang sebelumnya disetujui dalam aplikasi yang sama — di seluruh sesi KYC, KYB, dan API mandiri — ditambah temuan daftar blokir yang dikonfigurasi dalam daftar management-api. Verifikasi yang berbagi vendor_data sesi saat ini dikecualikan (pengguna akhir yang sama tidak mencocokkan diri mereka sendiri), array dibatasi hingga maksimal 5 entri, diurutkan dari yang paling lama. Ketika alamat berada di daftar blokir Anda tetapi tidak ada sesi yang cocok yang masuk daftar blokir, entri sintetis dengan source: "list_entry" (semua kolom sesi bernilai null) ditambahkan di awal array.

Contoh

Disetujui — OTP bersih dengan satu pelanggaran informasional

Ditolak — alamat yang tidak dapat dijangkau

Alamat yang diisi sebelumnya yang gagal dalam validasi sintaks atau DNS (MX) — atau yang email OTP-nya tidak dapat dikirimkan — segera diselesaikan sebagai Declined. Tidak ada event pemeriksaan kode yang muncul karena tidak ada kode yang pernah sampai ke pengguna.

Ditolak — kotak surat sekali pakai yang masuk daftar blokir

Pengguna menyelesaikan OTP, tetapi alamat tersebut cocok dengan daftar blokir email Anda (penolakan otomatis). Tanda alamat sekali pakai juga dimunculkan — di sini pada tingkat information karena disposable_email_action dibiarkan pada nilai defaultnya NO_ACTION.

Terkait

Terakhir diubah pada 7 November 2026