प्रमाणीकरण
इस प्रबंधन API के सभी endpoints आपकी एप्लिकेशन API कुंजी का उपयोग करते हैं। URL में org/app UUID की ज़रूरत नहीं है, क्योंकि एप्लिकेशन आपकी कुंजी से पहचानी जाती है।वर्कफ़्लो
वर्कफ़्लो तय करते हैं कि आपके उपयोगकर्ताओं को किन सत्यापन चरणों से गुजरना होगा (ID स्कैन, लाइवनेस, चेहरा मिलान, AML स्क्रीनिंग, आदि)। हर वर्कफ़्लो एक पुनः प्रयोज्य कॉन्फ़िगरेशन है, जिसे आप सत्रों से जोड़ते हैं।GET
आपके एप्लिकेशन के सभी वर्कफ़्लो की सूची देखें। हर वर्कफ़्लो की सुविधाएँ, थ्रेशोल्ड, और यह भी कि वह डिफ़ॉल्ट है या नहीं, लौटाता है।
POST
नया वर्कफ़्लो बनाएँ। तय करें कि कौन-सी सत्यापन सुविधाएँ सक्षम हों, थ्रेशोल्ड सेट करें, स्वीकृत दस्तावेज़ प्रकार कॉन्फ़िगर करें, और बहुत कुछ।
GET
किसी विशिष्ट वर्कफ़्लो का पूरा विवरण पाएँ, जिसमें सभी सुविधा कॉन्फ़िगरेशन और थ्रेशोल्ड शामिल हैं।
PATCH
वर्कफ़्लो कॉन्फ़िगरेशन अपडेट करें। आप किसी भी सुविधा सेटिंग, थ्रेशोल्ड, या स्वीकृत दस्तावेज़ों में बदलाव कर सकते हैं।
DELETE
वर्कफ़्लो हटाएँ। जो सत्र पहले से इस वर्कफ़्लो का उपयोग कर रहे हैं, उन पर कोई असर नहीं पड़ता।
त्वरित उदाहरण: वर्कफ़्लो बनाना
workflow_type मूल सुविधा सेट तय करता है। अलग-अलग सुविधाएँ is_*_enabled फ़्लैग से चालू या बंद की जाती हैं।
workflow_type के उपलब्ध मान: kyc, kyb, adaptive_age_verification, biometric_authentication, address_verification, questionnaire_verification, email_verification, phone_verification।
kyc वर्कफ़्लो में पहचान सत्यापन अपने आप शामिल होता है, इसके लिए अलग फ़्लैग की ज़रूरत नहीं है। वैकल्पिक सुविधाएँ जोड़ने या हटाने के लिए is_*_enabled फ़्लैग का उपयोग करें, जैसे चेहरा मिलान, लाइवनेस, AML, NFC, फ़ोन, ईमेल, पते का प्रमाण, डिवाइस और IP विश्लेषण, और अन्य।
फिर सत्र बनाते समय वर्कफ़्लो का उपयोग करें:
प्रश्नावलियाँ
सत्यापन वर्कफ़्लो में जोड़े जा सकने वाले कस्टम फ़ॉर्म, जिनसे उपयोगकर्ताओं से अतिरिक्त जानकारी ली जाती है।GET
सभी प्रश्नावलियों की सूची देखें।
POST
कस्टम प्रश्नों, ब्रांचिंग लॉजिक और अनुवादों के साथ नई प्रश्नावली बनाएँ।
GET
प्रश्नावली का विवरण पाएँ, जिसमें सभी प्रश्न और फ़ॉर्म की संरचना शामिल है।
PATCH
प्रश्नावली अपडेट करें।
DELETE
प्रश्नावली हटाएँ।
उपयोगकर्ता
अपने एप्लिकेशन में सत्यापित व्यक्तियों (उपयोगकर्ताओं) का प्रबंधन करें। हर उपयोगकर्ता की पहचान एकvendor_data स्ट्रिंग से होती है, जिसे आप सत्र बनाते समय देते हैं।
GET
आपके एप्लिकेशन के सभी उपयोगकर्ताओं की सूची देखें, जिसमें उनकी सत्यापन स्थिति और सत्र इतिहास शामिल है।
GET
अपने vendor_data पहचानकर्ता से उपयोगकर्ता का विवरण पाएँ।
PATCH
उपयोगकर्ता का मेटाडेटा अपडेट करें।
POST
उपयोगकर्ताओं को बैच में हटाएँ। बॉडी:
{"vendor_data_list": ["user-1", "user-2"]} या {"delete_all": true}। इससे उन उपयोगकर्ताओं के लिए रखे गए सभी बायोमेट्रिक टेम्पलेट भी स्थायी रूप से हटा दिए जाते हैं।बायोमेट्रिक टेम्पलेट
इमेज-रहित चेहरे के वे बायोमेट्रिक टेम्पलेट, जिन्हें ऑप्ट-इन करने वाला एप्लिकेशन सत्र हटाने के बाद भी रखता है। देखें बायोमेट्रिक टेम्पलेट।GET
फ़िल्टर के साथ पेजिनेटेड सूची (
vendor_data, vendor_user_uuid, status, source_type, retained_from, retained_to, ordering)।GET
उन्हीं फ़िल्टर के साथ गिनती।
GET
एक टेम्पलेट: जिस उपयोगकर्ता का यह टेम्पलेट है, उद्गम संदर्भ, समाप्ति, निर्देश, स्थिति।
DELETE
एक टेम्पलेट को स्थायी रूप से हटाएँ। लौटाता है
{"uuid": "...", "outcome": "purged" | "already_purged"}।POST
बल्क में स्थायी रूप से हटाना। बॉडी:
{"template_uuids": [...]} या {"delete_all": true}, साथ में वैकल्पिक फ़िल्टर।सत्र संचालन
POST
सत्रों को बैच में हटाएँ। इसके लिए
delete:sessions अनुमति चाहिए। बॉडी: {"session_numbers": ["1", "2", "3"]} या {"delete_all": true} (delete_all को filter_ से शुरू होने वाले सत्र सूची फ़िल्टर से सीमित करें, जैसे filter_status), साथ में वैकल्पिक retain_face_embeddings, face_retention_days, face_retention_deadline, deletion_instruction, और instruction_id। अधिकतम 20 मिलते सत्र होने पर 200 लौटता है, जिसमें हर सत्र के लिए face_retention_outcome होता है। इससे अधिक होने पर 202 लौटता है, जिसके साथ एक डिलीशन जॉब आता है।GET
202 लौटाने वाले बल्क सत्र हटाने की प्रगति और परिणामों की गिनती।GET
सत्र के लिए समीक्षाओं और गतिविधि लॉग की सूची।
POST
सत्र में समीक्षा नोट या स्थिति परिवर्तन जोड़ें।
बिलिंग
GET
मौजूदा क्रेडिट बैलेंस और ऑटो-रीफ़िल सेटिंग्स प्राप्त करें।
POST
क्रेडिट टॉप अप करने के लिए Stripe चेकआउट सत्र बनाएँ। प्रत्येक टॉप अप $50 से $20,000 के बीच होता है और उसे अंकित मूल्य पर जोड़ा जाता है।
सूचियाँ (ब्लॉकलिस्ट, एलाउलिस्ट और कस्टम)
ब्लॉकलिस्टिंग, एलाउलिस्टिंग और कस्टम वर्कफ़्लो शर्तों के लिए प्रकार-आधारित सूचियाँ प्रबंधित करें। पूरा सूचियों का API दस्तावेज़ीकरण देखें।GET
एप्लिकेशन की सभी सूचियाँ सूचीबद्ध करें (ब्लॉकलिस्ट, एलाउलिस्ट, कस्टम)।
POST
किसी सूची में एक प्रविष्टि जोड़ें। सत्र से डेटा स्वतः निकालने के लिए
reference_session_id समर्थित है, और लेन-देन/उपयोगकर्ता/व्यवसाय तक ट्रेसेबिलिटी के लिए reference_object_uuid समर्थित है।DELETE
किसी सूची से एक प्रविष्टि हटाएँ।
POST
चेहरा ब्लॉकलिस्ट में एक चेहरे की छवि (base64) अपलोड करें।
Webhook कॉन्फ़िगरेशन
GET
Webhook की मौजूदा कॉन्फ़िगरेशन प्राप्त करें, जिसमें URL, वर्शन, webhook हस्ताक्षर सत्यापित करने के लिए सीक्रेट कुंजी, और एप्लिकेशन की डेटा प्रतिधारण व बायोमेट्रिक-टेम्पलेट प्रतिधारण नीति शामिल हैं।
रिस्पॉन्स में
allowed_domains भी शामिल होता है, जिसका वर्णन नीचे PATCH /v3/webhook/ के अंतर्गत है।PATCH
Webhook URL, वर्शन अपडेट करें, या सीक्रेट कुंजी रोटेट करें। नया webhook सीक्रेट बनाने के लिए
rotate_secret_key: true सेट करें (पुराना सीक्रेट तुरंत अमान्य हो जाता है)। यह एप्लिकेशन की प्रतिधारण नीति भी सेट करता है: data_retention_months, और face_retention_policy (डिफ़ॉल्ट delete_with_session, या retain_until_user_deleted) जिसके साथ प्रतिधारण सक्षम होने पर अनिवार्य, सीमित face_retention_days (1-3650) देना होता है। देखें बायोमेट्रिक टेम्पलेट प्रतिधारण। यह allowed_return_hosts भी पंजीकृत करता है: अधिकतम 20 सादे होस्टनेम (उदाहरण के लिए app.example.com, बिना स्कीम, पोर्ट, पाथ या वाइल्डकार्ड के) जिन पर डिजिटल ID वॉलेट API सत्यापन व्यक्ति को HTTPS पर वापस भेज सकता है। नई सूची पंजीकृत सूची की जगह ले लेती है, और आपके एप्लिकेशन का व्हाइट लेबल डोमेन हमेशा अनुमत रहता है।यह allowed_domains भी सेट करता है: अधिकतम 50 वेब ओरिजिन (उदाहरण के लिए https://app.example.com) जिनमें होस्टेड सत्यापन फ़्लो एम्बेड किया जा सकता है और जिन पर वह सत्र callback के साथ उपयोगकर्ता को वापस भेज सकता है।
हर प्रविष्टि एक स्कीम, एक होस्ट और एक वैकल्पिक पोर्ट होती है, जिसमें कोई पाथ, क्वेरी या वाइल्डकार्ड नहीं होता।
https का उपयोग करें; http केवल localhost, 127.0.0.1 और ::1 के लिए स्वीकार किया जाता है।
Didit हर ओरिजिन को लोअर केस में, बिना डिफ़ॉल्ट पोर्ट के संग्रहित करता है, और सूची को allowed_domains में लौटाता है।
अमान्य प्रविष्टि allowed_domains पर 400 के साथ विफल होती है।
नई सूची पंजीकृत सूची की जगह ले लेती है, और खाली सूची प्रतिबंध हटा देती है।
जब तक सूची खाली नहीं है, POST /v3/session/ उसके बाहर के वेब callback को 400 के साथ अस्वीकार करता है, और होस्टेड फ़्लो उपयोगकर्ता को सूची से बाहर के संग्रहित या वर्कफ़्लो-डिफ़ॉल्ट कॉलबैक पर रीडायरेक्ट नहीं करता।
कस्टम URL स्कीम (ऐप डीप लिंक) और सर्वर-से-सर्वर API कॉल प्रभावित नहीं होते।यदि आप endpoints भेजते हैं, तो सूची में शामिल न किया गया हर webhook गंतव्य उसके साइनिंग सीक्रेट और उसके पूरे डिलीवरी लॉग सहित स्थायी रूप से हटा दिया जाता है, बिल्कुल वैसे ही जैसे DELETE /v3/webhook/destinations/{destination_uuid}/।
यह पूर्ववत नहीं किया जा सकता।
गंतव्यों को एक-एक करके प्रबंधित करने के लिए इसके बजाय webhook गंतव्य endpoint का उपयोग करें।