मुख्य सामग्री पर जाएं
PATCH
curl

यह क्या करता है

एक सत्यापन सत्र अलग-अलग सुविधाओं (चरणों) से मिलकर बनता है: ID/OCR, लाइवनेस डिटेक्शन, चेहरा मिलान, AML, पते का प्रमाण, फ़ोन, आदि। यह endpoint आपको उनमें से एक चरण की स्थिति Approved, Declined, या In Review पर सेट करने देता है। जब आप पूरे सत्र को स्वीकृत, अस्वीकृत या दोबारा खोलना चाहते हैं, तो update-status का उपयोग करें। जब आप केवल एक चरण पर निर्णय दर्ज करना चाहते हैं, जैसे अपनी समीक्षा प्रक्रिया के लिए चेहरा मिलान चरण को Declined चिह्नित करना, तब इस endpoint का उपयोग करें। जिस सत्र का पहले से निर्णय है, वह निर्णय बना रहता है: केवल चरण बदलता है। यदि सत्र पर अभी कोई निर्णय नहीं है और उसका वर्कफ़्लो ठीक इसी चरण की प्रतीक्षा कर रहा है, तो ओवरराइड लागू होने पर चरण पूरा हो जाता है, जैसे सामान्य रूप से पूरा होने पर होता। वर्कफ़्लो आगे बढ़ता है, बाद के चरण चलते हैं, और एक स्थिति नोड सत्र का निर्णय सेट कर सकता है और status.updated webhook भेज सकता है।

node_id से चरण चुनना

ग्राफ़-आधारित वर्कफ़्लो में हर चरण का एक node_id होता है (जैसे feature_ocr_1, feature_liveness_1, feature_aml_1)। इन्हें सत्र निर्णय में पाया जा सकता है। V3 निर्णय में हर सुविधा अपना node_id साथ लेकर आती है। गैर-ग्राफ़ (एकल-चरण) वर्कफ़्लो में अंतर्निहित सुविधा का कोई नोड ID नहीं होता। ऐसे चरण को लक्षित करने के लिए nodeId के रूप में शाब्दिक मान default भेजें। चूँकि ऐसे वर्कफ़्लो के किसी भी चरण का नोड ID नहीं होता, इसलिए feature_type भी भेजें (जैसे LIVENESS, AML या FACE_MATCH) ताकि बताया जा सके कि आप किस चरण की बात कर रहे हैं। अज्ञात feature_type पर 400 लौटता है।

व्यक्ति के फ़्लो पूरा होने तक प्रतीक्षा करें

डिफ़ॉल्ट रूप से ओवरराइड तुरंत लागू होता है। यदि व्यक्ति अभी भी फ़्लो से गुज़र रहा है, तो यह चल रहे फ़्लो के अंतर्गत किसी चरण को बदलता है; तब ओवरराइड forced: true के साथ दर्ज होता है। प्रतीक्षा करने के लिए defer_until_flow_finishes: true सेट करें। जब तक सत्र Not Started, In Progress या Resubmitted में है और व्यक्ति ने फ़्लो पूरा नहीं किया है, ओवरराइड pending_until_flow_finishes के रूप में संग्रहीत होता है। यह तब लागू होता है जब व्यक्ति फ़्लो पूरा करता है और फ़्लो अपने निर्णय तक पहुँचता है। जिस सत्र का फ़्लो पहले ही समाप्त हो चुका है, उस पर यह दोनों स्थितियों में तुरंत लागू होता है। प्रतीक्षारत ओवरराइड लागू होने के बजाय रद्द हो जाता है जब:
  • व्यक्ति पूरा करने से पहले चरण दोबारा करता है (check_changed),
  • उसी चरण पर नया ओवरराइड उसकी जगह ले लेता है (replaced),
  • सत्र अधूरे फ़्लो से बाहर चला जाता है: छोड़ा गया, समय-सीमा समाप्त, या फ़्लो के बीच निर्णय लिया गया (session_closed),
  • आप सुविधा ओवरराइड रद्द करें से उसे रद्द करते हैं (cancelled_by_reviewer)।
प्रतिक्रिया का override बताता है कि क्या हुआ: state applied या pending_until_flow_finishes होता है, और लागू होने पर applied_at सेट हो जाता है। शीर्ष-स्तरीय new_status चरण की संग्रहीत स्थिति है, इसलिए ओवरराइड प्रतीक्षा करते समय यह नहीं बदलता। किसी सत्र के हर ओवरराइड और यह देखने के लिए कि व्यक्ति अब भी फ़्लो में है या नहीं, सुविधा ओवरराइड सूची देखें का उपयोग करें।

KYC और KYB समर्थन

उपयोगकर्ता सत्यापन (KYC) और व्यवसाय सत्यापन (KYB) सत्रों के लिए यह बिल्कुल एक जैसे काम करता है: Didit दोनों में sessionId को पहचानता है। समर्थित चरण प्रकारों में ID/OCR, लाइवनेस डिटेक्शन, चेहरा मिलान, NFC, AML, पते का प्रमाण, फ़ोन, ईमेल सत्यापन, डेटाबेस सत्यापन, प्रश्नावलियाँ, और KYB रजिस्ट्री, दस्तावेज़ तथा प्रमुख व्यक्तियों की जाँच शामिल हैं।
स्टैंडअलोन API सत्र (जो स्टैंडअलोन सत्यापन APIs के ज़रिए बनाए गए हैं, session_type = API) पर अलग-अलग सुविधाओं की स्थिति नहीं बदली जा सकती। endpoint 400 लौटाता है।

उदाहरण

अपडेट के बाद क्या होता है

  • webhook: जब ओवरराइड लागू होता है, चाहे तुरंत या फ़्लो पूरा होने पर, तब data.updated इवेंट भेजा जाता है। प्रतीक्षा के दौरान या रद्द होने पर कुछ नहीं भेजा जाता।
  • गतिविधि: हर ओवरराइड सत्र की गतिविधि में FEATURE_OVERRIDE_PENDING, FEATURE_OVERRIDE_APPLIED या FEATURE_OVERRIDE_CANCELLED के रूप में दर्ज होता है, साथ में कर्ता (API कुंजी, उपयोगकर्ता, या प्रतीक्षारत ओवरराइड लागू होने पर सिस्टम)। अनुरोध की प्रविष्टि में आपका comment कारण के रूप में होता है। सत्र निर्णय के reviews सरणी में ये प्रविष्टियाँ new_status: null के साथ दिखती हैं, और अनुरोध की प्रविष्टि में आपका कारण comment में होता है।
  • सत्र निर्णय: जिस सत्र का पहले से निर्णय है, वह उसे बनाए रखता है। अंतिम निर्णय बदलने के लिए update-status को अलग से कॉल करें।

अनुमति

write:sessions विशेषाधिकार की आवश्यकता है, साथ ही या तो क्लाइंट API कुंजी (x-api-key) या उपयोगकर्ता प्राधिकरण हेडर चाहिए। स्कोप्ड API कुंजी को निर्णयों पर लिखने की पहुँच चाहिए।

संबंधित

प्राधिकरण

x-api-key
string
header
आवश्यक

आपकी एप्लिकेशन की API कुंजी, Business Console में Developers -> API keys से। प्राथमिक कुंजी के पास पूर्ण एक्सेस होता है। एक नामित कुंजी को स्कोप किया जा सकता है: प्रति संसाधन none, read या write, कुछ वर्कफ़्लो या स्वीकृत सत्रों तक सीमित, IP पतों की सूची तक सीमित, और समाप्ति तिथि तक सीमित। 401 का अर्थ है कि कुंजी गलत है, निरस्त कर दी गई है या उसकी समय-सीमा समाप्त हो गई है; 403 का अर्थ है कि कोई कुंजी नहीं भेजी गई थी, कुंजी के पास इस संसाधन या कार्रवाई का एक्सेस नहीं है, या अनुरोध उसकी IP सूची से बाहर के पते से आया था; सत्र रूट पर 404 का अर्थ है कि सत्र कुंजी के वर्कफ़्लो या स्थितियों से बाहर है। मीडिया एक्सेस के बिना एक कुंजी को छवि, वीडियो और PDF URL null के रूप में प्राप्त होते हैं, और सत्र write के बिना एक कुंजी को सत्र लिंक और token null के रूप में प्राप्त होते हैं। देखें https://docs.didit.me/console/api-keys।

पथ पैरामीटर

sessionId
string<uuid>
आवश्यक

सत्यापन सत्र का UUID। उपयोगकर्ता (KYC) और व्यवसाय (KYB) दोनों सत्र ID स्वीकार करता है — सेवा दोनों सत्र प्रकारों में ID को रिज़ॉल्व करती है।

उदाहरण:

"11111111-2222-3333-4444-555555555555"

nodeId
string
आवश्यक

अपडेट की जाने वाली सुविधा का वर्कफ़्लो ग्राफ़ नोड ID (उदाहरण के लिए feature_ocr_1)। गैर-ग्राफ़ (एकल-चरण) वर्कफ़्लो के लिए लिटरल मान default का उपयोग करें जहां सुविधा का कोई नोड ID नहीं है।

उदाहरण:

"feature_ocr_1"

बॉडी

application/json
new_status
enum<string>
आवश्यक

इस सुविधा के लिए लक्षित स्थिति। वर्तमान मान से भिन्न होनी चाहिए।

उपलब्ध विकल्प:
Approved,
Declined,
In Review
उदाहरण:

"Approved"

comment
string

इस सुविधा परिवर्तन के लिए सत्र के समीक्षा ट्रेल पर रिकॉर्ड किया गया वैकल्पिक फ़्री-टेक्स्ट नोट।

उदाहरण:

"Document manually verified by compliance."

feature_type
enum<string>

किस प्रकार के चरण को लक्षित करना है। गैर-ग्राफ़ वर्कफ़्लो (nodeId = default) पर आवश्यक है, जहाँ कोई भी चरण नोड साझा नहीं करता है; अन्यथा वैकल्पिक। एक अज्ञात मान 400 लौटाता है।

उपलब्ध विकल्प:
ID_VERIFICATION,
OCR,
OCR_BACK,
NFC,
LIVENESS,
FACE,
AGE_ESTIMATION,
AGE_VERIFICATION,
FACE_SEARCH,
FACE_MATCH,
IP_ANALYSIS,
AML,
PHONE,
PHONE_VERIFICATION,
EMAIL,
EMAIL_VERIFICATION,
POA,
PROOF_OF_ADDRESS,
DATABASE_VALIDATION,
DATA_VALIDATION,
QUESTIONNAIRE,
DOCUMENT_AI,
KYB_REGISTRY,
KYB_DOCUMENTS,
KYB_KEY_PEOPLE,
BANK_VERIFICATION,
GEOLOCATION
उदाहरण:

"LIVENESS"

defer_until_flow_finishes
boolean
डिफ़ॉल्ट:false

जब व्यक्ति अभी भी फ़्लो में है, तो ओवरराइड को तुरंत लागू करने के बजाय pending_until_flow_finishes के रूप में स्टोर करें और फ़्लो समाप्त होने पर लागू करें। छोड़े जाने पर या false होने पर, ओवरराइड तुरंत लागू होता है। ऐसे सत्र पर जिसका फ़्लो पहले ही समाप्त हो चुका है, यह दोनों ही मामलों में तुरंत लागू होता है।

उदाहरण:

false

प्रतिक्रिया

ओवरराइड रिकॉर्ड किया गया था। new_status चेक की संग्रहीत स्थिति है: ओवरराइड लागू होने के बाद अनुरोधित स्थिति, फ़्लो पूरा होने की प्रतीक्षा करते समय अपरिवर्तित स्थिति। override बताता है कि क्या हुआ।

session_id
string<uuid>
आवश्यक
node_id
string | null
आवश्यक

अपडेट किए गए चरण का वर्कफ़्लो नोड, या बिना नोड वाले चरण के लिए null (गैर-ग्राफ़ वर्कफ़्लो में default पाथ)।

उदाहरण:

"feature_ocr_1"

feature_type
string
आवश्यक

अपडेट की गई सुविधा का मॉडल नाम (उदा. KYC, Face, FaceMatch, AML, POA)।

उदाहरण:

"KYC"

new_status
string
आवश्यक

जाँच की संग्रहीत स्थिति: ओवरराइड लागू होने के बाद अनुरोध की गई स्थिति, जबकि ओवरराइड प्रवाह पूरा होने की प्रतीक्षा करता है तो अपरिवर्तित स्थिति।

उदाहरण:

"Approved"

override
object
आवश्यक

PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/ के साथ किए गए चेक (सुविधा) स्थिति का एक ओवरराइड: यह क्या बदलता है, क्या यह लागू हुआ या अभी भी व्यक्ति द्वारा फ़्लो पूरा करने की प्रतीक्षा कर रहा है, किसने अनुरोध किया और क्यों।

अंतिम संशोधन 7 नवंबर 2026