Langsung ke konten utama
Panduan ini memandu Anda melalui alur lengkap untuk mengintegrasikan verifikasi identitas Didit melalui REST API: mendapatkan kredensial, membuat sesi, menampilkannya kepada pengguna, dan menerima hasilnya.

Langkah 1: Dapatkan Kredensial Anda

Ada dua cara untuk memperoleh api_key:

Opsi A: Pendaftaran secara programatik (tanpa browser)

Cocok untuk CI/CD dan agen AI. Dua panggilan API, yaitu POST /programmatic/register/ lalu POST /programmatic/verify-email/, akan mengembalikan api_key secara langsung. → Lihat Pendaftaran Programmatic untuk alur lengkap, aturan kata sandi, masa berlaku JWT, dan kebijakan penguncian.

Opsi B: Dari Didit Console

  1. Buka Didit Console.
  2. Buat atau pilih organisasi Anda.
  3. Buka Pengaturan → API & Webhook.
  4. Salin:
    • Kunci API: digunakan sebagai header x-api-key pada setiap panggilan verifikasi.
    • Kunci Rahasia Webhook: digunakan untuk memverifikasi tanda tangan HMAC webhook.

Variabel lingkungan


Langkah 2: Buat Alur Kerja

Sebelum membuat sesi, Anda memerlukan alur kerja verifikasi. Alur kerja menentukan langkah verifikasi apa saja yang dilalui pengguna.

Buat di Console

  1. Buka Didit Console → Alur kerja
  2. Klik Buat Alur Kerja
  3. Pilih templat dasar:
  1. Tambahkan fitur opsional:
  1. Salin ID Alur Kerja Anda.
Lihat Dokumentasi Alur Kerja untuk opsi konfigurasi yang lebih rinci.

Langkah 3: Buat Sesi Verifikasi

Panggil API untuk membuat sesi bagi pengguna Anda.

Permintaan

Parameter Permintaan

Contoh Lengkap dengan Semua Opsi

expected_details.expected_document_types membatasi langkah verifikasi identitas hanya pada jenis dokumen tertentu. Layar pemilihan dokumen hanya menampilkan jenis yang diminta. Nilai yang diizinkan: P (paspor), ID (kartu identitas nasional), DL (surat izin mengemudi), RP (izin tinggal), HIC (kartu asuransi kesehatan), TC (kartu pajak), SSC (kartu jaminan sosial). Nilai tidak peka huruf besar-kecil dan duplikat dihapus; nilai yang tidak dikenali akan mengembalikan 400. Lihat Referensi Pembuatan Sesi untuk skema lengkap.

Respons

201 Created:

Kolom Respons Utama

Idempotensi. Jika vendor_data disertakan dan sudah ada sesi yang belum selesai (Not Started, In Progress, Resubmitted, atau Awaiting User) dengan vendor_data yang sama pada versi alur kerja terbaru yang dipublikasikan, sesi yang ada tersebut akan dikembalikan (tetap 201) alih-alih membuat duplikat. Nilai callback dan metadata sesi tersebut diperbarui ke nilai baru, dan status mencerminkan sesi yang ada.
Jika x-api-key tidak ada, akan dikembalikan 403 dengan {"detail": "You do not have permission to perform this action."}, sama dengan respons untuk kunci yang valid tetapi tidak memiliki izin. Kunci yang salah, dicabut, atau kedaluwarsa akan mengembalikan 401. Kredit yang tidak cukup mengembalikan 400. Lihat Referensi API Pembuatan Sesi untuk dokumentasi lengkap.

Langkah 4: Tampilkan Verifikasi kepada Pengguna

Pilih cara menampilkan alur verifikasi kepada pengguna Anda:

Opsi A: SDK Native (direkomendasikan untuk mobile)

Gunakan session_token dengan SDK native untuk integrasi kamera, NFC, dan biometrik. → SDK iOS · SDK Android · React Native · Flutter

Opsi B: iframe InContext (direkomendasikan untuk web)

Sematkan verifikasi di halaman Anda menggunakan url yang dikembalikan pada Langkah 3.
→ iframe InContext

Opsi C: Pengalihan

Alihkan pengguna ke URL verifikasi.
→ Pengalihan web

Opsi D: WebView Mobile

Untuk aplikasi mobile tanpa SDK native.
→ WebView di iOS/Android

Langkah 5: Menerima Hasil

Melalui Webhook (Direkomendasikan)

Webhook memberi tahu server Anda secara waktu nyata saat status verifikasi berubah. Pengaturan:
  1. Buat tujuan webhook di Console (API & Webhook) atau melalui POST /v3/webhook/destinations/ dengan webhook_version: "v3" dan array subscribed_events (misalnya ["status.updated"])
  2. Simpan secret_shared_key yang dikembalikan saat pembuatan: kunci ini adalah rahasia HMAC untuk semua varian tanda tangan
  3. Terapkan endpoint webhook di server Anda
Contoh payload webhook: Di dalam decision, setiap hasil per fitur dikirim sebagai array jamak (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …), satu entri untuk setiap node dalam alur kerja. Ini adalah kontrak V3 dan bersifat tetap: jangan pernah menulis kode yang bergantung pada kunci tunggal nfc / id_verification / liveness.
Objek decision hanya ada saat status bernilai Approved, Declined, In Review, atau Abandoned (event Resubmitted membawa resubmit_info sebagai gantinya). Didit menggunakan event_id yang sama di seluruh percobaan ulang dan tujuan distribusi, jadi gunakan itu sebagai kunci idempotensi Anda. Lihat Model data untuk setiap array jamak dan kolom. Verifikasi tanda tangan (X-Signature-V2, direkomendasikan): X-Signature-V2 adalah HMAC-SHA256 atas penyandian ulang kanonis dari badan JSON: float dengan nilai utuh diubah menjadi integer, kunci diurutkan secara rekursif, pemisah ringkas, dan Unicode dipertahankan.
→ Dokumentasi webhook lengkap, termasuk X-Signature berbasis byte mentah, X-Signature-Simple yang sudah usang dan hanya memeriksa envelope pembungkus, serta cara memilih di antara keduanya. Didit mencoba ulang pengiriman yang gagal (5xx, 404, timeout) hingga 2 kali (sekitar 1 menit, lalu sekitar 4 menit) dan menghentikan pengiriman setelah 5 detik. Pastikan server Anda segera mengembalikan 2xx.

Melalui API (opsional)

Ambil payload keputusan yang sama kapan saja:
Bentuk respons (array jamak) identik dengan objek decision di dalam payload webhook, dan endpoint ini dapat dipanggil pada titik mana pun dalam siklus hidup sesi. Gunakan webhook untuk pembaruan real-time dan sisakan panggilan API untuk pengisian data susulan, audit, dan pembangunan ulang. Endpoint /decision/ dibatasi 600 permintaan GET per menit per kunci API (lihat Batas laju). Untuk semantik error: session_id yang tidak dikenal mengembalikan 404 dengan {"detail": "Not found."}, kegagalan autentikasi muncul sebagai 403, dan endpoint ini tidak pernah mengembalikan 401. URL media dalam respons adalah tautan yang ditandatangani sebelumnya dan berumur pendek, jadi ambil segera dan jangan menyimpannya. → Referensi API untuk mengambil sesi

Contoh Kode Lengkap

Node.js / Express

Python / FastAPI


Status sesi

Ini adalah 10 nilai yang mungkin untuk status, berupa string yang tepat dan peka huruf besar-kecil (perhatikan bahwa Kyc Expired menggunakan huruf K kapital tunggal): Lihat Status verifikasi untuk siklus hidup lengkap, transisi, dan diagram Mermaid.

Langkah selanjutnya

  1. Pilih metode integrasi Anda:
  2. Konfigurasikan webhook: Webhook
  3. Rencanakan kapasitas: Batas laju
  4. Tangani setiap status: Status verifikasi
  5. Sesuaikan alur kerja Anda: Alur kerja
  6. Pastikan API dapat dijangkau: Healthcheck

Butuh bantuan?

Terakhir diubah pada 7 November 2026