> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# API Autentikasi Biometrik: KYC Tanpa Kata Sandi

> Autentikasi pengguna lama dengan liveness & pencocokan wajah Didit. Tanpa dokumen, verifikasi tanpa sandi <2 detik. Bayar $0.10/panggilan.

Solusi Autentikasi Biometrik Didit memberikan pengalaman verifikasi yang efisien bagi pengguna yang kembali. Alur kerja ini dapat dikonfigurasi untuk melakukan pemeriksaan liveness saja untuk verifikasi kehadiran sederhana, atau menggabungkan liveness dengan pengenalan wajah untuk konfirmasi identitas yang lebih kuat terhadap potret yang tersimpan. Fleksibilitas ini menciptakan pengalaman yang lancar sembari mempertahankan standar keamanan yang tinggi.

Prompt Integrasi Autentikasi Biometrik
        Salin prompt ke papan klip



      
      

\<pre>

\````# Goal
Integrate Didit Biometric Authentication (passwordless re-verification of returning users) into your app.

\# Delivery mode
Biometric Authentication is **session-only**. There is no dedicated /v3/biometric-auth/ endpoint. It is delivered through a session whose workflow is configured for biometric-auth use (workflow_type=BIOMETRIC_AUTHENTICATION). Under the hood it reuses the same LivenessV3 + FaceMatchV3 serializers as the regular KYC flow — the only difference is the reference image source.

\# Reference image resolution (create time)
The reference face the live selfie is matched against comes from one of two places:
\- `portrait_image` (Base64, max 2MB) sent in the create-session request: always wins when provided.
\- Omitted `portrait_image`: Didit reuses a face already stored for the `vendor_data` user, resolved in this order: (1) face captured during an approved liveness check, (2) ePassport chip photo from an approved ID verification, (3) portrait cropped from the ID document of an approved ID verification, (4) a manually enrolled profile face (Users API / Console upload).
\- If `portrait_image` is omitted and the user has NO stored face, session creation fails with 400: {"portrait_image": "No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first."}
\- If `portrait_image` is omitted and `vendor_data` is missing too, session creation fails with 400: {"portrait_image": "A portrait image is required to perform face match for this workflow. Send a portrait_image, or provide the vendor_data of a user with a previously stored face image to reuse it."}

\# Steps
1\. Create a Biometric Auth workflow in the Business Console (workflow_type=BIOMETRIC_AUTHENTICATION). Configure the LIVENESS method (PASSIVE / ACTIVE_3D / FLASHING) and the FACE_MATCH similarity threshold.
2\. The returning user must already have a face on file under the same `vendor_data` (approved verification with liveness or ID document, or an enrolled profile face); otherwise send `portrait_image` explicitly.
3\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. Use the **same vendor_data** as the user's prior verification so the stored face can be retrieved. Add `portrait_image` only to override the stored face.
4\. Open session.url for the user (or mount the Web/Mobile SDK).
5\. Fetch the decision — GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated.

curl example:
\```bash
curl -X POST 'https://verification.didit.me/v3/session/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
"vendor_data": "user-1234",
"callback": "https://yourapp.com/post-reauth"
}'
\```

\# Decision surface
Biometric Authentication surfaces results across **two arrays** on the decision payload — there is no biometric_auths[] array:
\- `liveness_checks[]` — the live capture (status + score + warnings under LogWarningChoices.LIVENESS).
\- `face_matches[]` — the comparison against the stored portrait (status + score + warnings under LogWarningChoices.FACEMATCH).

Approve the user only when **both** entries are status="Approved".

\# Status enum (per liveness_checks[].status and face_matches[].status)
"Not Started" | "In Progress" | "Approved" | "In Review" | "Declined" | "Abandoned" | "Kyc Expired"

\# Warnings
\- Liveness side (LogWarningChoices.LIVENESS): LOW_LIVENESS_SCORE, LIVENESS_FACE_ATTACK, NO_FACE_DETECTED, MULTIPLE_FACES_DETECTED, FACE_IN_BLOCKLIST, DUPLICATED_FACE.
\- Face Match side (LogWarningChoices.FACEMATCH): LOW_FACE_MATCH_SIMILARITY, NO_REFERENCE_IMAGE.
Full catalogue: /core-technology/biometric-auth/warnings-biometric-authentication.

\# Failure modes to handle
\- 400 on session creation with the "No stored face image was found for this user" message: the user has no stored face under this vendor_data; route them to first-time KYC, or send portrait_image explicitly.
\- NO_REFERENCE_IMAGE on face_matches[] — the reference image could not be resolved at match time; route the user to first-time KYC instead.
\- LOW_FACE_MATCH_SIMILARITY — the live selfie does not match the stored portrait; do not authenticate.
\- LIVENESS_FACE_ATTACK — presentation attack detected; reject and flag the account.
\- FACE_IN_BLOCKLIST — user has been added to your blocklist since enrolment; block.

\# See also
\- Canonical schema: /reference/data-models#biometric-authentication (and /reference/data-models#liveness-check, /reference/data-models#face-match)
\- Per-feature report: /core-technology/biometric-auth/report-biometric-authentication
\- Risk catalogue: /core-technology/biometric-auth/warnings-biometric-authentication
\- Full integration playbook: /integration/integration-prompt````

\</pre>



      
      

Tempel ke

## Fitur Utama#### Verifikasi Ulang Cepat- Tidak memerlukan pemindaian dokumen
- Selesaikan verifikasi dalam hitungan detik
- Mengurangi friksi dan drop-off pengguna#### Keamanan Tingkat Lanjut- Menggunakan arsitektur jaringan neural yang sama dengan Pencocokan Wajah 1:1
- Mencegah upaya pengambilalihan akun
- Menyertakan deteksi liveness untuk mencegah spoofing#### Fleksibilitas Integrasi- Tersedia berbasis web
- Ambang batas kecocokan yang dapat dikonfigurasi
- Analisis Perangkat & IP opsional untuk keamanan yang ditingkatkan## Cara Kerja**1. Pembuatan Sesi**Saat Anda membuat sesi autentikasi biometrik untuk alur kerja dengan **pencocokan wajah**, Didit memerlukan wajah referensi untuk membandingkan swafoto yang diambil secara langsung.
Anda memiliki dua opsi:- **Kirim `portrait_image`** dalam Base64 (maks. 2MB) dari database Anda sendiri. Opsi ini selalu diprioritaskan jika disediakan.
- **Hilangkan `portrait_image`** dan teruskan `vendor_data` pengguna. Didit secara otomatis menggunakan kembali wajah yang sudah tersimpan untuk pengguna tersebut, yang dicari dalam urutan berikut:
  1. Wajah yang diambil selama **pemeriksaan liveness yang disetujui**
  2. **Foto dari chip ePassport** dari verifikasi identitas yang disetujui
  3. **Potret yang dipotong dari dokumen identitas** dari verifikasi identitas yang disetujui
  4. **Wajah profil yang didaftarkan secara manual** (Users API atau unggahan melalui Console)```json theme={null}
{
  "workflow_id": "11111111-2222-3333-4444-555555555555",
  "vendor_data": "user-123",
  "callback": "https://example.com/verification/callback",
  "metadata": { "login_attempt": "2" }
}
```> [!WARNING]
>
> Hanya wajah dari sesi yang **disetujui** (atau wajah yang Anda daftarkan sendiri) yang dapat digunakan kembali. Jika Anda menghilangkan `portrait_image` dan pengguna tidak memiliki wajah yang tersimpan, pembuatan sesi gagal dengan kode `400` dan pesan `No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first.` Jika Anda juga menghilangkan `vendor_data`, pesan `400` meminta Anda untuk mengirimkan `portrait_image` atau `vendor_data` dengan wajah yang tersimpan.**2. Pengambilan Foto Langsung**Selama proses autentikasi:| Pemeriksaan | Deskripsi |
| - | - |
| **Verifikasi liveness** | Mencegah spoofing menggunakan Passive Liveness atau 3D Action & Flash |
| **Kualitas gambar** | Sistem mengevaluasi pencahayaan, posisi, dan kejernihan |
| **Panduan coba lagi** | Gambar berkualitas buruk ditolak dengan instruksi perbaikan |
| **Umpan balik waktu nyata** | Pengguna melihat panduan pemosisian untuk pengambilan gambar yang optimal |**3. Verifikasi & Pemrosesan Hasil**Sistem memproses verifikasi berdasarkan konfigurasi alur kerja Anda:> [accordion] Mode Hanya Liveness
>
> Jika **Pencocokan Wajah dinonaktifkan** dalam alur kerja, sistem hanya mengonfirmasi liveness pengguna; wajah referensi tidak diperlukan dan `portrait_image` tidak diwajibkan. Pemeriksaan yang berhasil menghasilkan autentikasi yang **disetujui**, berguna untuk verifikasi kehadiran sederhana.> [accordion] Mode Liveness + Pencocokan Wajah
>
> Jika **Pencocokan Wajah diaktifkan** dalam alur kerja (wajah referensi dari `portrait_image` atau wajah tersimpan pengguna):
>
> 1. Sistem melakukan **pemeriksaan liveness** terlebih dahulu
> 2. Jika liveness lolos, sistem membandingkan swafoto baru dengan wajah referensi
> 3. **Skor kemiripan (0–100%)** dihasilkan
> 4. Skor di atas ambang batas yang dikonfigurasi → **Disetujui**
> 5. Skor di bawah ambang batas → **Ditolak**Hasil tersedia melalui **respons API**, **Business Console**, dan **webhook**.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.