उपयोगकर्ता CRUD API: विक्रेता उपयोगकर्ता संचालन

मुख्य उपयोगकर्ता इकाई का प्रबंधन /v3/users/ के अंतर्गत सार्वजनिक endpoints से होता है। प्रोफ़ाइल से जुड़े अटैचमेंट, जैसे आयात किया गया चेहरा अपलोड करना, didit_internal_id के साथ organization/application path का उपयोग करते हैं। यह पेज अवधारणात्मक मार्गदर्शन देता है। पूरे अनुरोध और रिस्पॉन्स स्कीमा के लिए API reference देखें।

उपयोगकर्ताओं की सूची देखें

GET /v3/users/ आपके एप्लिकेशन के उपयोगकर्ताओं की पृष्ठांकित सूची लौटाता है। स्थिति, खोज, तारीख सीमा और अन्य चीज़ों पर फ़िल्टर समर्थित हैं।

curl -G https://verification.didit.me/v3/users/ \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "status=ACTIVE" \
  --data-urlencode "search=jane" \
  --data-urlencode "page_size=50"

उपयोग के उदाहरण:

हर दिन उपयोगकर्ताओं के एक हिस्से को अपने डेटा वेयरहाउस में सिंक करें।
विश्लेषक कतार के लिए चिह्नित उपयोगकर्ता खोजें।
प्रदर्शन नाम से उपयोगकर्ता खोजें।

एक उपयोगकर्ता प्राप्त करें

GET /v3/users/{vendor_data}/ vendor_data से एक उपयोगकर्ता प्राप्त करें। यह समेकित काउंटर सहित पूरा डेटा मॉडल लौटाता है।

curl https://verification.didit.me/v3/users/user-42/ \
  -H "x-api-key: YOUR_API_KEY"

URL में vendor_data केस-संवेदी है। हमेशा वही सटीक मान भेजें जो आपने सत्र बनाते समय उपयोग किया था।

उपयोगकर्ता बनाएँ

POST /v3/users/create/ कोई भी सत्र चलने से पहले उपयोगकर्ता इकाई बनाएँ। इनके लिए उपयोगी है:

ग्राहक सत्यापन करने से पहले metadata या कस्टम फ़ील्ड सेट करना।
प्रारंभिक स्थिति सेट करना (जैसे FLAGGED, जब आपकी ऑनबोर्डिंग टीम मैन्युअल दस्तावेज़ों की समीक्षा कर रही हो)।
मौजूदा डेटाबेस से उपयोगकर्ता पहले से लोड करना, ताकि पहले दिन से पूरी सूची तैयार हो।

curl -X POST https://verification.didit.me/v3/users/create/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data": "user-42",
    "display_name": "Jane Doe",
    "metadata": { "tier": "premium", "signup_source": "web" }
  }'

यदि vendor_data वाला उपयोगकर्ता पहले से मौजूद है, तो कॉल कॉन्फ़्लिक्ट त्रुटि लौटाती है। अपडेट करने के लिए इसके बजाय PATCH का उपयोग करें। आप संपर्क विवरण भी भेज सकते हैं: first_name और last_name (यदि आप एक नहीं भेजते तो इन्हें मिलाकर full_name बनाया जाता है), email, phone_number और country। Didit email और phone_number को metadata.contact में, और country को metadata.address में संग्रहीत करता है। उसी कॉल में व्यक्ति को सत्यापन के लिए आमंत्रित करने हेतु email और workflow_id के साथ send_verification_link: true जोड़ें। Didit उस वर्कफ़्लो पर व्यक्ति के लिए एक सत्यापन सत्र बनाता है और उसे लिंक ईमेल करता है। प्रतिक्रिया का verification_link सत्र का session_id, session_number, status, url, workflow_id और email देता है। यदि आप लिंक नहीं माँगते, तो यह null होता है। जाँच और त्रुटियों के लिए Create User देखें।

आयातित चेहरा अपलोड करें

POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/ किसी मौजूदा उपयोगकर्ता प्रोफ़ाइल से एक विश्वसनीय चेहरे की छवि जोड़ें। यदि आप किसी दूसरे प्रदाता से उपयोगकर्ता आयात करते हैं और चाहते हैं कि पहले Didit सत्र से पहले Didit उनके चेहरे का प्रमाण सँभाले, तो यह सही अगला कदम है।

# First create or retrieve the User and read didit_internal_id from the response.
curl -X POST https://verification.didit.me/v3/organization/$ORGANIZATION_ID/application/$APPLICATION_ID/vendor-users/by-id/$DIDIT_INTERNAL_ID/faces/upload/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "image": "<base64-encoded-jpg-or-png>",
    "comment": "Imported from previous KYC provider"
  }'

अनुरोध फ़ील्ड, सीमाओं, सूची बनाने और हटाने वाले endpoints और ब्लॉकलिस्ट के अंतर के लिए Upload User Face देखें।

उपयोगकर्ता अपडेट करें

PATCH /v3/users/{vendor_data}/ बदले जा सकने वाले प्रोफ़ाइल फ़ील्ड अपडेट करें। सत्यापित सत्रों से प्राप्त अधिकांश फ़ील्ड केवल पढ़ने योग्य हैं। PATCH से इन्हें बदलने की कोशिश को या तो अनदेखा किया जाएगा या ऑडिट लॉग में चिह्नित किया जाएगा। बदले जा सकने वाले फ़ील्ड: display_name, metadata, tags। सत्यापन के बाद केवल पढ़ने योग्य: full_name, date_of_birth, portrait_image, सभी समेकित काउंटर, features map।

curl -X PATCH https://verification.didit.me/v3/users/user-42/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "metadata": { "tier": "enterprise" } }'

changed_fields array के साथ user.data.updated webhook भेजा जाता है।

स्थिति बदलें

PATCH /v3/users/{vendor_data}/update-status/ किसी उपयोगकर्ता को ACTIVE, FLAGGED और BLOCKED के बीच ले जाएँ। स्थिति में बदलाव आने वाले सत्रों और लेन-देन पर लागू होता है।

curl -X PATCH https://verification.didit.me/v3/users/user-42/update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "BLOCKED",
    "reason": "Chargeback fraud pattern detected"
  }'

से → तक	सामान्य ट्रिगर
`ACTIVE` → `FLAGGED`	लेन-देन नियम, विश्लेषक की समीक्षा, सतत AML निगरानी में मिलान
`ACTIVE` → `BLOCKED`	पुष्ट धोखाधड़ी, मैन्युअल ब्लॉकलिस्ट प्रविष्टि, ब्लॉकलिस्ट मिलान
`FLAGGED` → `ACTIVE`	विश्लेषक ने समीक्षा को मंज़ूर किया
`BLOCKED` → `ACTIVE`	विश्लेषक द्वारा मैन्युअल अनब्लॉक

user.status.updated webhook भेजा जाता है।

उपयोगकर्ता हटाएँ (बैच)

POST /v3/users/delete/ एक या अधिक उपयोगकर्ता हटाएँ। उपयोगकर्ता रिकॉर्ड स्थायी रूप से हटा दिए जाते हैं, साथ ही सत्र हटने के बाद उनके लिए रखा गया हर बायोमेट्रिक टेम्पलेट भी। उनके सत्यापन सत्र इस endpoint से कवर नहीं होते। वे बने रहते हैं, और उपयोगकर्ता से उनका लिंक हट जाता है। उन्हें Delete Session या Batch Delete Sessions से हटाएँ। लेन-देन भी कवर नहीं होते। उन्हें Console से हटाएँ।

curl -X POST https://verification.didit.me/v3/users/delete/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data_list": ["user-42", "user-43", "user-44"]
  }'

उपयोगकर्ताओं को vendor_data_list, didit_internal_id_list, या दोनों एक साथ से चुनें। या एप्लिकेशन के हर उपयोगकर्ता को हटाने के लिए delete_all: true भेजें। Console के filter_* बैच पैरामीटर यहाँ अनदेखे नहीं किए जाते, बल्कि 400 के साथ अस्वीकार कर दिए जाते हैं, ताकि सीमित इरादा कभी पूर्ण सफ़ाए में न बदले। यह प्रति-आइटम परिणाम के बजाय एक गिनती लौटाता है: {"deleted": <int>}। जो पहचानकर्ता किसी से मेल नहीं खाते, वे चुपचाप छोड़ दिए जाते हैं। इसलिए यदि आप deleted की तुलना अपने भेजे गए पहचानकर्ताओं की संख्या से करना चाहते हैं, तो डुप्लिकेट-रहित सूची भेजें।

अनुमति मॉडल

API कुंजियाँ एक ही एप्लिकेशन की होती हैं। प्राथमिक सीक्रेट और पूर्ण-पहुँच कुंजियाँ उस एप्लिकेशन के हर /v3/users/* endpoint को कॉल कर सकती हैं, delete सहित। एक सीमित API कुंजी को People (users) की पहुँच चाहिए: GET endpoints के लिए पढ़ने की पहुँच, और create, update, status बदलने तथा delete के लिए लिखने की पहुँच। send_verification_link: true के साथ उपयोगकर्ता बनाने के लिए Sessions write भी चाहिए, क्योंकि यह एक सत्र बनाता है और उसका लिंक ईमेल करता है। जिस कुंजी के पास ज़रूरी पहुँच नहीं है, वह 403 देती है। जो कुंजी केवल कुछ वर्कफ़्लो या स्वीकृत सत्रों तक सीमित है, वह /v3/users/* endpoints तक बिल्कुल नहीं पहुँच सकती। भूमिकाएँ Console की अवधारणा हैं। users अनुमति संसाधन और उसके claims तय करते हैं कि कोई टीम सदस्य Console में क्या कर सकता है, और API कुंजी के अनुरोधों के लिए इनका मूल्यांकन नहीं होता। उस मैट्रिक्स के लिए Roles & permissions देखें। किसी सेवा को उपयोगकर्ता हटाने से रोकने के लिए, उसे People की केवल पढ़ने की पहुँच वाली कुंजी दें, या People की कोई पहुँच न दें।

रेट लिमिट और आइडेम्पोटेंसी

सभी /v3/users/* endpoints पर मानक रेट लिमिट लागू होती हैं।
create idempotent नहीं है। उसी vendor_data के साथ दोबारा प्रयास करने पर कॉन्फ़्लिक्ट लौटता है। अपनी ओर से डुप्लिकेट हटाएँ, या हमेशा पहले GET करें।
delete idempotent है। पहले से हटाए गए उपयोगकर्ता को हटाना कोई बदलाव नहीं करता।

इन ऑपरेशनों द्वारा भेजे गए webhooks

ऑपरेशन	Webhook
`create`	create कॉल के लिए कोई webhook नहीं भेजा जाता। पहला `user.data.updated` तब आता है जब कोई सत्र या अपडेट पहली बार प्रोफ़ाइल भरता है
`update`	`user.data.updated` (`changed_fields` के साथ)
`update-status`	`user.status.updated`
`delete`	कोई नहीं। यदि आपको इस पर प्रतिक्रिया देनी है, तो हटाए जाने को अपने सिस्टम में दर्ज करें

अगले चरण

डेटा मॉडल

पूर्ण फ़ील्ड संदर्भ।

सूची API

GET /v3/users/ स्कीमा।

निर्माण API

POST /v3/users/create/ स्कीमा।

चेहरा अपलोड करें

उपयोगकर्ता प्रोफ़ाइल में आयातित चेहरे की छवियाँ जोड़ें।

अवलोकन

मूल्य निर्धारण

वर्कफ़्लो और सत्यापन

समीक्षा और संचालन

एंटिटी (उपयोगकर्ता और व्यवसाय)

सेटिंग्स और कस्टमाइज़ेशन

सुरक्षा और अनुपालन

Didit Academy

संसाधन

उपयोगकर्ता CRUD API: विक्रेता उपयोगकर्ता संचालन

उपयोगकर्ताओं की सूची देखें

एक उपयोगकर्ता प्राप्त करें

उपयोगकर्ता बनाएँ

आयातित चेहरा अपलोड करें

उपयोगकर्ता अपडेट करें

स्थिति बदलें

उपयोगकर्ता हटाएँ (बैच)

अनुमति मॉडल

रेट लिमिट और आइडेम्पोटेंसी

इन ऑपरेशनों द्वारा भेजे गए webhooks

अगले चरण

डेटा मॉडल

सूची API

निर्माण API

चेहरा अपलोड करें

​उपयोगकर्ताओं की सूची देखें

​एक उपयोगकर्ता प्राप्त करें

​उपयोगकर्ता बनाएँ

​आयातित चेहरा अपलोड करें

​उपयोगकर्ता अपडेट करें

​स्थिति बदलें

​उपयोगकर्ता हटाएँ (बैच)

​अनुमति मॉडल

​रेट लिमिट और आइडेम्पोटेंसी

​इन ऑपरेशनों द्वारा भेजे गए webhooks

​अगले चरण

डेटा मॉडल

सूची API

निर्माण API

चेहरा अपलोड करें

उपयोगकर्ताओं की सूची देखें

एक उपयोगकर्ता प्राप्त करें

उपयोगकर्ता बनाएँ

आयातित चेहरा अपलोड करें

उपयोगकर्ता अपडेट करें

स्थिति बदलें

उपयोगकर्ता हटाएँ (बैच)

अनुमति मॉडल

रेट लिमिट और आइडेम्पोटेंसी

इन ऑपरेशनों द्वारा भेजे गए webhooks

अगले चरण