Langsung ke konten utama
POST
cURL

Dukungan KYC dan KYB

Satu endpoint membuat sesi Verifikasi Pengguna dan Verifikasi Bisnis sekaligus. Jenis alur kerja menentukan jenis sesi yang dibuat:
  • Kirim workflow_id alur kerja KYC → sesi Verifikasi Pengguna (KYC) dibuat. Respons session_kind: "user".
  • Kirim workflow_id alur kerja KYB → sesi Verifikasi Bisnis (KYB) dibuat. Respons session_kind: "business".
Atur alur kerja di konsol pada Alur kerja → Buat alur kerja. Alur kerja adalah KYC atau KYB saat dibuat, dan jenisnya tidak dapat diubah setelah itu.

Contoh

Respons (201 Dibuat):

Dokumen Tanda Tangan Elektronik

Jika alur kerja memiliki langkah Tanda Tangan Elektronik yang mengambil dokumen dari sesi (signature_documents_source diatur ke session atau both), kirimkan dokumen tersebut di sign.documents. Setiap dokumen berupa file dalam base64, sehingga Didit tidak perlu mengambilnya dari URL.
Tanpa fields, penandatangan membaca dokumen dan menyetujuinya.

Menempatkan kolom dengan teks penanda

Alih-alih posisi, kolom dapat memuat anchor: potongan teks dalam dokumen yang menandai tempat kolom diletakkan. Penanda cocok untuk dokumen yang Anda buat untuk setiap sesi, misalnya dari templat Word. Untuk dokumen alur kerja, tempatkan kolom di konsol. Jika teks tidak ada dalam dokumen, panggilan mengembalikan 400 dengan field_anchor_not_found dan kunci kolom tersebut. Didit tidak menghapus teks penanda dari PDF, jadi tulis teks tersebut dengan warna yang sama dengan latar belakang halaman.

Nilai kolom

sign.field_values mengatur nilai setiap kolom yang prefill-nya adalah api.<key>, baik pada dokumen alur kerja maupun dokumen sesi. Nilainya berupa objek yang diindeks dengan nama <key> tersebut. Nilai berupa string 1 sampai 500 karakter untuk kolom text dan data, dan boolean untuk checkbox.

Error dan panggilan berulang

Sesi menampung hingga 20 dokumen dan total 50 MB. Panggilan mengembalikan 400 dengan error sign ketika:
  • Alur kerja tidak memiliki langkah Tanda Tangan Elektronik.
  • Anda mengirim sign.documents, sedangkan langkah tersebut hanya mengambil dokumen alur kerja.
  • Langkah tersebut hanya mengambil dokumen sesi dan Anda tidak mengirim dokumen apa pun, atau langkah tersebut tidak memiliki dokumen alur kerja dan Anda tidak mengirim dokumen apa pun.
  • Dokumen terlalu besar, bukan base64 yang valid, atau bukan file yang didukung.
  • File Word ditolak dengan signature_document_not_supported, atau tidak dapat dikonversi dan mengembalikan signature_document_conversion_failed, masing-masing dengan reason yang tercantum di File yang didukung.
  • Kolom tidak valid, penandanya tidak ditemukan (field_anchor_not_found), atau nilai kolom ditolak.
Memanggil operasi pembuatan lagi untuk workflow_id dan vendor_data yang sama akan mengembalikan sesi yang tertunda. Jika panggilan tersebut mengirim sign, dokumen, kolom, dan nilai kolomnya harus sama persis dengan yang pertama (urutan, judul, nama file, konten, kolom, dan nilainya). Perbedaan apa pun akan mengembalikan 400 dengan {"sign": "signature_document_changed"}. Dalam kasus itu, gunakan vendor_data yang berbeda, atau tunggu sampai sesi yang tertunda selesai.

Pengujian dengan skenario sandbox

Pada aplikasi mode sandbox, kirimkan sandbox_scenario untuk memuat hasil yang deterministik (setujui, penolakan tertentu, atau skenario dalam peninjauan) tanpa menyentuh penyedia sungguhan atau saldo Anda:
sandbox_scenario ditolak dengan 400 pada aplikasi produksi. Jika Anda belum mengetahui hasilnya saat pembuatan sesi, aktifkan (atau aktifkan ulang) nanti melalui POST /v3/session/{session_id}/sandbox/arm/, selama sesi masih Not Started. Pemilih skenario sebelum alur pada halaman verifikasi yang di-hosting menggunakan endpoint yang sama. Lihat Sandbox & Data Pengujian untuk katalog skenario lengkap, registri nilai khusus, dan bentuk permintaan serta respons endpoint pengaktifan.

vendor_data mengikat sesi ke entitas

  • Untuk alur kerja KYC: mengikat ke entitas pengguna. Jika pengguna belum ada, entitas tersebut dibuat otomatis.
  • Untuk alur kerja KYB: mengikat ke entitas bisnis. Dibuat otomatis jika entitas tersebut baru.
Pelajari selengkapnya di penautan data vendor.

Persetujuan biometrik di Illinois, Texas, dan Colorado

Alur yang di-hosting dan SDK native 4.10.0 atau yang lebih baru dapat menampilkan langkah persetujuan biometrik yang eksplisit sebelum pengambilan wajah pertama, bergantung pada mode persetujuan aplikasi dan lokasi orang tersebut. Dua kolom opsional memengaruhi keputusan ini:
  • user_state: lokasi tempat tinggal orang tersebut, jika Anda mengetahuinya (US-IL, IL atau Illinois). Dalam mode Auto, negara bagian yang tercakup membuat alur meminta persetujuan.
  • biometric_consent: objek dengan given_at dan text_version, untuk persetujuan yang sudah Anda kumpulkan. Alur tidak akan meminta persetujuan lagi.
SDK native di bawah 4.10.0 tidak dapat menampilkan langkah ini: sesinya berjalan seperti biasa dan hasil keputusan menunjukkan bahwa persetujuan belum dikumpulkan. Lihat Persetujuan biometrik.

Penting: pengungkapan dan persetujuan tetap dilakukan di produk Anda

Create Session menghasilkan URL verifikasi dan token sesi. Endpoint ini tidak dengan sendirinya membuktikan bahwa Anda telah menyampaikan pemberitahuan kepada pengguna atau memperoleh persetujuan yang diwajibkan untuk kasus penggunaan spesifik Anda. Jika Anda memulai sesi Didit dari aplikasi, situs web, pembungkus SDK, atau alur White Label Anda sendiri, Anda sebaiknya menangani lapisan hukum di UX Anda sendiri sebelum pengguna mulai pengambilan data.

Daftar periksa pra-verifikasi yang direkomendasikan

  1. Beri tahu pengguna bahwa perusahaan Anda meminta verifikasi ini dan bahwa Didit adalah penyedia verifikasi / prosesor yang mendukung alur ini.
  2. Tautkan ke pemberitahuan privasi Anda dan ketentuan hukum dari pihak pengendali data yang berlaku untuk proses ini.
  3. Tautkan ke Pemberitahuan Privasi Verifikasi dan Ketentuan Pengguna Akhir untuk Verifikasi Identitas milik Didit.
  4. Jika alur Anda mencakup pengambilan dokumen, swafoto, liveness, atau biometrik, kumpulkan persetujuan tegas yang eksplisit di mana pun hukum yang berlaku atau posisi hukum Anda mewajibkannya.
  5. Jika Anda menggunakan UI kustom, domain kustom, atau alur yang hanya menggunakan API, tampilkan pengungkapan ini di produk Anda sendiri sebelum mengarahkan pengguna ke alur Didit.
  6. Simpan catatan Anda sendiri tentang teks pemberitahuan / persetujuan, stempel waktu, dan metadata terkait jika tim hukum Anda memerlukan jejak audit.
Persyaratan hukum berbeda-beda di setiap yurisdiksi. Branding White Label tidak menghapus peran Didit dalam alur verifikasi. Tinjau implementasi Anda bersama penasihat hukum sebelum peluncuran jika Anda beroperasi di yurisdiksi dengan aturan khusus biometrik.

Otorisasi

x-api-key
string
header
wajib

Kunci API aplikasi Anda, dari Developers -> API keys di Business Console. Kunci utama memiliki akses penuh. Kunci bernama dapat diberi cakupan: none, read, atau write per sumber daya, dibatasi pada beberapa alur kerja atau pada sesi yang disetujui, pada daftar alamat IP, dan pada tanggal kedaluwarsa. 401 berarti kuncinya salah, dicabut, atau kedaluwarsa; 403 berarti tidak ada kunci yang dikirimkan, kunci tidak memiliki akses ke sumber daya atau tindakan ini, atau permintaan datang dari alamat di luar daftar IP-nya; 404 pada rute sesi berarti sesi berada di luar alur kerja atau status kunci tersebut. Kunci tanpa akses media menerima URL gambar, video, dan PDF sebagai null, dan kunci tanpa izin tulis sesi menerima tautan sesi dan token sebagai null. Lihat https://docs.didit.me/console/api-keys.

Body

application/json
workflow_id
string<uuid>
wajib

Pengidentifikasi stabil dari alur kerja yang menentukan langkah verifikasi mana yang akan dijalankan oleh sesi tersebut. Alur kerja dibuat dan dikelola di halaman Workflows pada Konsol. workflow_id juga secara implisit memilih apakah sesi tersebut adalah KYC atau KYB.

Contoh:

"11111111-2222-3333-4444-555555555555"

vendor_data
string

Pengidentifikasi unik untuk pengguna yang sedang diverifikasi, seperti UUID, email, atau ID pengguna internal. Kolom ini digunakan untuk: (1) Pengelompokan pengguna — sesi dengan vendor_data yang sama ditautkan ke profil pengguna yang sama di tab Pengguna. (2) Deteksi duplikat lintas-sesi — saat memeriksa duplikasi wajah, dokumen, nomor telepon, email, alamat IP, atau sidik jari perangkat, sesi dengan vendor_data yang sama diperlakukan sebagai pengguna yang sama dan dikecualikan dari kecocokan. Tanpa vendor_data, setiap sesi diperlakukan sebagai pengguna unik dan semua potensi duplikat ditampilkan. Kami sangat menyarankan untuk selalu menyertakan vendor_data guna mengurangi derau dalam deteksi duplikat.

Contoh:

"user-123"

multi_account_segment
string

Realm deteksi duplikat opsional di dalam organisasi Anda. Pemeriksaan wajah duplikat hanya membandingkan sesi ini dengan sesi lain yang memiliki segmen yang sama, sehingga basis akun yang terpisah (akun pribadi dan bisnis, atau satu per sub-klien B2B) tidak menandai seseorang yang secara sah memiliki satu akun di masing-masing basis akun. Abaikan untuk menggunakan realm default tunggal, yang saat ini digunakan oleh setiap sesi. Pencocokan daftar blokir dan allowlist mengabaikan kolom ini.

Maximum string length: 64
Contoh:

"business-accounts"

callback
string

URL untuk mengarahkan pengguna setelah verifikasi selesai. Didit secara otomatis menambahkan verificationSessionId dan status (Approved, Declined, In Review) sebagai parameter kueri. Skema URL kustom (misalnya myapp://) didukung untuk callback seluler. Jika tidak disertakan, callback_url default milik alur kerja akan digunakan. Jika aplikasi memiliki domain yang diizinkan (allowed_domains pada PATCH /v3/webhook/), callback http atau https harus berada di salah satu origin tersebut (skema, host, dan port yang sama), jika tidak, permintaan gagal dengan 400 pada callback: callback must be on one of the application's allowed domains: https://app.example.com. Skema URL kustom selalu diterima.

Contoh:

"https://example.com/verification/callback"

callback_method
enum<string>
default:initiator

Menentukan perangkat mana yang harus menangani pengalihan ke URL callback yang diberikan. Gunakan initiator untuk mengalihkan hanya perangkat yang memulai alur, completer untuk perangkat yang menyelesaikannya, atau both untuk mengizinkan salah satu perangkat memicu callback. Jika Anda mendapati callback tidak terpicu secara andal, kami sarankan untuk menyetel nilai ini ke both.

Opsi yang tersedia:
initiator,
completer,
both
Contoh:

"both"

metadata
any

JSON arbitrer yang disimpan bersama sesi dan dikembalikan dalam respons serta webhook. Nilai JSON apa pun diterima (objek, string, angka, array), tetapi objek JSON yang berisi pasangan kunci/nilai disarankan. Tidak ditampilkan kepada pengguna akhir. Gunakan ini untuk meneruskan ID korelasi Anda sendiri, varian A/B, atau konteks bisnis.

Contoh:
tags
string[]

Tag yang ditambahkan ke sesi saat dibuat, berdasarkan nama. Hingga 10 tag, masing-masing hingga 50 karakter. Nama tidak membedakan huruf besar/kecil dan disimpan dalam huruf besar. Nama yang belum ada di aplikasi akan dibuat sebagai tag baru. Tag ditampilkan pada sesi di konsol, tempat Anda dapat memfilternya.

Maximum array length: 10
Maximum string length: 50
Contoh:
language
enum<string>

Kode bahasa (ISO 639-1) untuk antarmuka proses verifikasi. Mengontrol bahasa yang ditampilkan kepada pengguna akhir selama verifikasi. Jika tidak diberikan, bahasa browser akan terdeteksi dan digunakan secara otomatis. Periksa semua bahasa yang didukung di sini.

Opsi yang tersedia:
en,
ar,
bg,
bn,
bs,
ca,
cnr,
cs,
da,
de,
el,
es,
et,
fa,
fi,
fr,
he,
hi,
hr,
hu,
hy,
id,
it,
ja,
ka,
kk,
ko,
ky,
lt,
lv,
mk,
mn,
ms,
nl,
no,
pl,
pt-BR,
pt,
ro,
ru,
sk,
sl,
so,
sq,
sr,
sv,
th,
tr,
uk,
uz,
vi,
zh-CN,
zh-TW,
zh
Contoh:

"en"

contact_details
object

Informasi kontak pengguna yang dapat digunakan untuk notifikasi, pra-pengisian formulir verifikasi, dan verifikasi telepon. Ini mencakup alamat email, bahasa pilihan untuk komunikasi, dan nomor telepon.

Contoh:
expected_details
object

Detail pengguna yang diharapkan yang digunakan untuk validasi silang terhadap data yang diekstraksi dari dokumen identitas pengguna, Bukti Alamat, dan langkah verifikasi lainnya. Ketidakcocokan dimunculkan sebagai peringatan pada keputusan; beberapa kolom (misalnya id_country, expected_document_types) juga mengubah alur bagi pengguna. Untuk alur kerja Verifikasi Bisnis (KYB), hanya kolom bisnis (company_name, registry_country, registration_number) yang digunakan — kolom-kolom ini mengisi otomatis pencarian registri perusahaan untuk pengguna — dan semua kolom tingkat orang diabaikan.

Contoh:
portrait_image
string<byte>

Gambar potret wajah pengguna akhir yang di-encode Base64 (maks 2MB; JPEG, PNG, WebP, atau TIFF). Digunakan sebagai gambar referensi untuk dicocokkan dengan tangkapan liveness saat alur kerja merupakan alur kerja Biometric Authentication dengan Pencocokan Wajah diaktifkan, atau alur kerja graf apa pun di mana Pencocokan Wajah berjalan sebelum Verifikasi Identitas (OCR). Opsional jika pengguna vendor_data sudah memiliki gambar wajah yang tersimpan: Didit menggunakannya kembali secara otomatis, ditentukan berdasarkan urutan prioritas: wajah liveness yang disetujui, foto chip ePassport, potret dokumen identitas, wajah profil yang didaftarkan secara manual (hanya wajah dari sesi yang disetujui atau wajah yang Anda daftarkan sendiri yang digunakan kembali). Jika diberikan, portrait_image selalu diutamakan daripada wajah yang tersimpan. Jika dihilangkan dan tidak ada wajah tersimpan yang ditemukan (atau vendor_data tidak dikirim), pembuatan sesi gagal dengan 400. Diabaikan untuk jenis alur kerja lainnya.

Contoh:

"iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="

sandbox_scenario
string

Slug skenario khusus sandbox. Hanya diterima jika kunci API milik aplikasi mode sandbox; ditolak pada aplikasi produksi. Saat disetel, alur pembuatan akan menyematkan nilai ajaib yang dibundel skenario ke dalam kolom input sesi (contact_details, expected_details) sehingga penyedia tiruan menghasilkan hasil skenario tersebut melalui alur kerja nyata. Lihat katalog skenario di GET /v1/sandbox/scenarios/ atau Sandbox & Data Uji. Anda juga dapat mengaktifkan (atau mengaktifkan ulang) skenario setelah pembuatan melalui POST /v3/session/{sessionId}/sandbox/arm/, selama sesi masih Not Started. Untuk pencarian non-dokumen, gunakan lookup_partial_match, lookup_no_match, atau lookup_provider_error untuk menguji anggaran percobaan dan fallback yang dikonfigurasi. Untuk dompet identitas, gunakan wallet_cancelled, wallet_timeout, atau wallet_provider_error; approve mensimulasikan dompet yang terverifikasi. Semua dompet katalog dapat diuji di sandbox, termasuk skema yang tidak tersedia di aplikasi produksi. Percobaan yang disimulasikan tidak dikenakan biaya.

Contoh:

"decline_document_expired"

sign
object

Input Tanda Tangan Elektronik untuk sesi ini. documents adalah dokumen yang akan ditandatangani, untuk alur kerja yang langkah Tanda Tangan Elektronik-nya mengambil dokumen dari sesi (signature_documents_source session atau both): hingga 20 dokumen dan total 50 MB. field_values mengisi kolom yang prefill-nya adalah api.<key>, baik pada dokumen alur kerja maupun sesi. Membuat sesi kembali untuk workflow_id dan vendor_data yang sama akan mengembalikan sesi yang tertunda; jika panggilan tersebut mengirimkan sign, dokumen, kolom, dan nilainya harus identik dengan yang pertama, dan perbedaan apa pun mengembalikan 400 dengan {"sign": "signature_document_changed"}. Lihat Dokumen Tanda Tangan Elektronik.

user_state
string

Tempat tinggal individu tersebut, jika Anda mengetahuinya: kode subdivisi ISO 3166-2 (US-IL, ES-M) atau kode atau nama negara bagian AS (IL, Illinois). Negara bagian yang hukumnya mewajibkan persetujuan biometrik eksplisit (Illinois, Texas, Colorado) membuat alur verifikasi memintanya sebelum mengambil wajah, dengan pemicu declared_state. Nilai yang tidak dikenali mengembalikan 400. Lihat Persetujuan biometrik.

Maximum string length: 16
Contoh:

"US-IL"

Persetujuan biometrik eksplisit yang telah Anda kumpulkan dari orang tersebut. Ini memenuhi persyaratan, sehingga alur verifikasi tidak meminta lagi, dan keputusan mencatatnya sebagai status: "given" dengan pemicu customer_collected. Jawaban yang sudah diberikan oleh orang tersebut dalam alur tidak pernah digantikan. Lihat Persetujuan biometrik.

Respons

Sesi dibuat (atau dikembalikan, jika sesi yang belum selesai dengan vendor_data yang sama sudah ada pada versi alur kerja terbaru yang dipublikasikan). Responsnya adalah sesi yang diserialisasi, termasuk url verifikasi yang di-hosting untuk mengarahkan pengguna.

session_id
string<uuid>
wajib

Pengenal unik sesi verifikasi. Gunakan id ini saat memanggil GET /v3/session/{sessionId}/decision/.

Contoh:

"11111111-2222-3333-4444-555555555555"

session_number
integer
wajib

Nomor urut yang mudah dibaca manusia dan ditetapkan ke sesi di dalam aplikasi Anda. Berguna untuk dukungan dan dasbor.

Contoh:

43762

session_token
string
wajib

Token 12 karakter yang aman untuk URL yang mengizinkan pengguna akhir untuk mengakses alur verifikasi yang di-hosting di url. Berlaku sampai sesi kedaluwarsa. Perlakukan sebagai rahasia — siapa pun yang memilikinya dapat membuka alur verifikasi untuk sesi ini.

Contoh:

"3FaJ9wLqX2Mz"

url
string<uri>
wajib

URL verifikasi yang di-hosting untuk mengarahkan pengguna akhir. URL ini menyematkan session_token dan, jika dikonfigurasi, menggunakan domain White Label Anda. Jika permintaan menyertakan language, URL tersebut berisi segmen jalur bahasa - https://verify.didit.me/{language}/session/{session_token} (misalnya /es/session/...); tanpa language, segmen tersebut dihilangkan.

Contoh:

"https://verify.didit.me/session/3FaJ9wLqX2Mz"

vendor_data
string | null
wajib

Pengenal yang Anda teruskan dalam permintaan untuk menautkan sesi ke pengguna atau bisnis di sistem Anda sendiri. Dikembalikan secara persis sama. Bernilai null jika tidak diberikan.

Contoh:

"user-123"

metadata
any
wajib

Payload JSON arbitrer yang Anda simpan bersama sesi pada saat pembuatan. Dikembalikan persis apa adanya — nilai JSON apa pun yang Anda kirim (objek, string, angka, array) dikembalikan sebagaimana mestinya, meskipun objek JSON disarankan. Tidak ditampilkan kepada pengguna akhir. Selalu ada dalam respons; null jika tidak diberikan pada saat pembuatan.

Contoh:
status
enum<string>
wajib

Status sesi saat ini. Sesi yang baru dibuat mengembalikan Not Started. Jika sesi yang belum selesai sudah ada untuk vendor_data yang sama pada versi publikasi terbaru dari alur kerja, status yang dikembalikan mencerminkan sesi yang sudah ada tersebut.

Opsi yang tersedia:
Not Started,
In Progress,
Approved,
Declined,
In Review,
Expired,
Abandoned,
Kyc Expired,
Resubmitted,
Awaiting User
Contoh:

"Not Started"

callback
string<uri> | null
wajib

URL pengalihan akhir tempat pengguna diarahkan setelah menyelesaikan alur. Didit menambahkan ?verificationSessionId={session_id}&status={status} ke URL ini. Kembali ke URL callback alur kerja yang dikonfigurasi jika tidak diberikan dalam permintaan; null jika keduanya tidak diatur. Jika aplikasi memiliki domain yang diizinkan dan URL ini adalah URL web di luar domain tersebut (misalnya default alur kerja yang diatur sebelum daftar diubah), alur yang di-hosting tidak mengalihkan pengguna ke URL tersebut.

Contoh:

"https://example.com/verification/callback"

workflow_id
string<uuid>
wajib

Pengidentifikasi stabil dari alur kerja tempat sesi ini berjalan. Selalu merupakan pengidentifikasi grup stabil dari alur kerja — meskipun Anda mereferensikan UUID versi alur kerja tertentu dalam permintaan (pencarian yang kompatibel dengan versi sebelumnya), respons tetap membawa workflow_id yang stabil. Gunakan ini untuk mengorelasikan sesi dengan alur kerja yang Anda konfigurasikan di Konsol.

Contoh:

"11111111-2222-3333-4444-555555555555"

workflow_version
integer
wajib

Nomor versi dari versi alur kerja yang dipublikasikan tempat sesi disematkan saat pembuatan. Didit menentukan versi alur kerja terbaru yang dipublikasikan untuk workflow_id saat sesi dibuat, dan sesi tetap menjalankan versi tersebut bahkan jika alur kerja dipublikasikan ulang nanti.

Contoh:

3

tags
string[]

Tag pada sesi, berdasarkan nama.

Contoh:
Terakhir diubah pada 7 November 2026