Langsung ke konten utama

Autentikasi

Semua endpoint API manajemen menggunakan kunci API aplikasi Anda. Tidak ada UUID org/app yang diperlukan di URL karena aplikasi diidentifikasi dari kunci Anda.
Belum punya kunci API? Daftar secara programatis dalam 2 panggilan API.

Alur Kerja

Alur kerja menentukan langkah verifikasi yang dijalani pengguna Anda (pemindaian ID, liveness, pencocokan wajah, skrining AML, dll.). Setiap alur kerja adalah konfigurasi yang dapat digunakan ulang dan dilampirkan ke sesi.
GET
Daftar semua alur kerja untuk aplikasi Anda. Mengembalikan fitur, ambang batas, dan apakah alur kerja tersebut merupakan nilai bawaan.
POST
Buat alur kerja baru. Tentukan fitur verifikasi yang akan diaktifkan, atur ambang batas, konfigurasikan jenis dokumen yang diterima, dan lainnya.
GET
Dapatkan detail lengkap dari alur kerja tertentu, termasuk semua konfigurasi fitur dan ambang batas.
PATCH
Perbarui konfigurasi alur kerja. Anda dapat mengubah pengaturan fitur, ambang batas, atau dokumen yang diterima.
DELETE
Hapus alur kerja. Sesi yang sudah menggunakan alur kerja ini tidak terpengaruh.
Kami sangat menyarankan penggunaan Konsol Bisnis untuk membuat dan mengonfigurasi alur kerja. Pembuat alur kerja visual menyediakan templat, konfigurasi fitur dengan seret dan lepas, pengaturan dokumen, penyesuaian ambang batas, dan pratinjau, tanpa perlu menulis kode. Gunakan API hanya untuk otomatisasi atau pengelolaan alur kerja secara programatis.

Contoh Cepat: Membuat Alur Kerja

Nilai workflow_type menentukan kumpulan fitur dasar. Fitur individual kemudian diaktifkan atau dinonaktifkan dengan flag is_*_enabled.
Nilai workflow_type yang tersedia: kyc, kyb, adaptive_age_verification, biometric_authentication, address_verification, questionnaire_verification, email_verification, phone_verification. Untuk alur kerja kyc, verifikasi identitas otomatis disertakan, sehingga Anda tidak memerlukan flag terpisah untuk itu. Gunakan flag is_*_enabled untuk menambah atau menghapus fitur opsional seperti pencocokan wajah, liveness, AML, NFC, telepon, email, bukti alamat, Analisis Perangkat & IP, dan lainnya. Kemudian gunakan alur kerja tersebut saat membuat sesi:

Kuesioner

Formulir kustom yang dapat Anda tambahkan ke alur kerja verifikasi untuk mengumpulkan informasi tambahan dari pengguna.
GET
Daftar semua kuesioner.
POST
Buat kuesioner baru dengan pertanyaan kustom, logika percabangan, dan terjemahan.
GET
Dapatkan detail kuesioner, termasuk semua pertanyaan dan struktur formulir.
PATCH
Perbarui kuesioner.
DELETE
Hapus kuesioner.

Pengguna

Kelola individu terverifikasi (pengguna) di aplikasi Anda. Setiap pengguna diidentifikasi oleh string vendor_data yang Anda berikan saat membuat sesi.
GET
Daftar semua pengguna untuk aplikasi Anda, termasuk status verifikasi dan riwayat sesinya.
GET
Dapatkan detail pengguna berdasarkan pengenal vendor_data Anda.
PATCH
Perbarui metadata pengguna.
POST
Hapus pengguna secara massal. Isi: {"vendor_data_list": ["user-1", "user-2"]} atau {"delete_all": true}. Juga menghapus permanen semua templat biometrik yang disimpan untuk pengguna tersebut.

Templat Biometrik

Templat biometrik wajah tanpa gambar yang disimpan oleh aplikasi yang telah memberikan persetujuan setelah sesi dihapus. Lihat Templat biometrik.
GET
Daftar berpaginasi dengan filter (vendor_data, vendor_user_uuid, status, source_type, retained_from, retained_to, ordering).
GET
Jumlah templat dengan filter yang sama.
GET
Satu templat: pengguna pemilik, referensi asal, tanggal kedaluwarsa, instruksi, dan status.
DELETE
Hapus permanen satu templat. Mengembalikan {"uuid": "...", "outcome": "purged" | "already_purged"}.
POST
Hapus permanen secara massal. Isi: {"template_uuids": [...]} atau {"delete_all": true} ditambah filter opsional.

Operasi Sesi

POST
Hapus sesi secara massal. Membutuhkan delete:sessions. Isi: {"session_numbers": ["1", "2", "3"]} atau {"delete_all": true} (persempit delete_all dengan filter Daftar Sesi yang diawali filter_, seperti filter_status), ditambah retain_face_embeddings, face_retention_days, face_retention_deadline, deletion_instruction, dan instruction_id yang bersifat opsional. Hingga 20 sesi yang cocok mengembalikan 200 dengan face_retention_outcome untuk setiap sesi; lebih dari itu mengembalikan 202 dengan tugas penghapusan.
GET
Progres dan jumlah setiap hasil dari penghapusan sesi massal yang mengembalikan 202.
GET
Daftar tinjauan dan log aktivitas untuk sesi.
POST
Tambahkan catatan tinjauan atau perubahan status ke sesi.

Penagihan

GET
Mengambil saldo kredit saat ini dan pengaturan isi ulang otomatis.
POST
Membuat sesi checkout Stripe untuk mengisi ulang kredit. Setiap isi ulang bernilai $50 hingga $20,000 dan ditambahkan sesuai nilai nominalnya.

Daftar (Daftar Blokir, Daftar Izin & Kustom)

Kelola daftar bertipe untuk pemblokiran, penambahan ke daftar izin, dan kondisi alur kerja kustom. Lihat dokumentasi lengkap API Daftar.
GET
Mencantumkan semua daftar untuk aplikasi (daftar blokir, daftar izin, kustom).
POST
Menambahkan entri ke daftar. Mendukung reference_session_id untuk mengekstrak data secara otomatis dari sesi, dan reference_object_uuid untuk keterlacakan ke transaksi/pengguna/bisnis.
DELETE
Menghapus entri dari daftar.
POST
Mengunggah gambar wajah ke daftar blokir wajah (base64).

Konfigurasi Webhook

GET
Mengambil konfigurasi webhook saat ini, termasuk URL, versi, kunci rahasia untuk memverifikasi tanda tangan webhook, serta kebijakan retensi data dan kebijakan retensi templat biometrik aplikasi. Respons juga memuat allowed_domains, yang dijelaskan di bawah PATCH /v3/webhook/.
PATCH
Perbarui URL webhook, versi, atau lakukan rotasi kunci rahasia. Setel rotate_secret_key: true untuk membuat rahasia webhook baru (rahasia lama langsung tidak berlaku). Juga menetapkan kebijakan retensi aplikasi: data_retention_months, dan face_retention_policy (delete_with_session sebagai default, atau retain_until_user_deleted) beserta face_retention_days yang wajib diisi dengan nilai berhingga (1-3650) saat retensi diaktifkan. Lihat Retensi templat biometrik. Juga mendaftarkan allowed_return_hosts: hingga 20 nama host saja (misalnya app.example.com, tanpa skema, port, path, atau wildcard) yang boleh menjadi tujuan pengembalian pengguna melalui HTTPS setelah verifikasi API dompet ID digital. Daftar baru menggantikan daftar yang sudah terdaftar, dan domain White Label aplikasi Anda selalu diizinkan.Juga menetapkan allowed_domains: hingga 50 origin web (misalnya https://app.example.com) tempat alur verifikasi yang di-hosting boleh disematkan dan tempat pengguna boleh dikembalikan dengan callback sesi. Setiap entri terdiri dari skema, host, dan port opsional, tanpa path, query, atau wildcard. Gunakan https; http hanya diterima untuk localhost, 127.0.0.1, dan ::1. Didit menyimpan setiap origin dalam huruf kecil tanpa port default, dan mengembalikan daftar tersebut di allowed_domains. Entri yang tidak valid gagal dengan 400 pada allowed_domains. Daftar baru menggantikan daftar yang sudah terdaftar, dan daftar kosong menghapus pembatasan. Selama daftar tidak kosong, POST /v3/session/ menolak callback web di luar daftar tersebut dengan 400, dan alur yang di-hosting tidak mengarahkan pengguna ke callback tersimpan atau callback default alur kerja yang berada di luar daftar tersebut. Skema URL kustom (deep link aplikasi) dan panggilan API server-ke-server tidak terpengaruh.Jika Anda mengirim endpoints, setiap tujuan webhook yang tidak tercantum dalam daftar akan dihapus secara permanen, beserta rahasia penandatanganannya dan seluruh log pengirimannya, sama seperti DELETE /v3/webhook/destinations/{destination_uuid}/. Tindakan ini tidak dapat dibatalkan. Untuk mengelola tujuan satu per satu, gunakan endpoint tujuan webhook sebagai gantinya.

Ringkasan Lengkap Endpoint API

Terakhir diubah pada 7 November 2026