पहचान या पते का प्रमाण संलग्न करें
इस चरण का उपयोग तब करें जब पहचान या पता मौजूद हो और उसकी आवश्यक फ़ाइलें इस माध्यम से अपलोड की जा चुकी हों: create_encrypt_files। अपलोड के लिए चयनित प्रमाण प्रकार का उपयोग करें। वर्तमान पहचानकर्ता यहाँ से लें: get_proof_types। यह पहचानकर्ता आवश्यकता और इकाई की श्रेणी से मेल खाना चाहिए।
identity_id और address_id को सहेजकर रखें, जो यहाँ से मिलते हैं: create_document; प्रोफ़ाइल का UUID अलग होता है। नई बनाई गई प्रोफ़ाइलों में बाद में पते का प्रमाण संलग्न करने की संगतता की समीक्षा अभी जारी है। यदि पता अस्वीकार हो जाए, तो दोबारा प्रयास करने से पहले पोर्टल में जाँच करें या सहायता टीम से संपर्क करें।
प्रमाण बनाएँ
सक्षम MultiTEL API खाते और उसके लिए अनुमत आईपी पते का उपयोग करें। उदाहरणों में परिवेश चरों से लिए गए HTTP Basic क्रेडेंशियल का उपयोग होता है; अपने खाते के प्रकार के अनुसार प्रमाणीकरण के नियमों का पालन करें। अनुरोध HTTPS के माध्यम से भेजें। HTTP प्रतिक्रिया के साथ-साथ JSON में यह मान भी जाँचें: status.code; अनुप्रयोग संबंधी त्रुटियाँ HTTP 200 के साथ भी आ सकती हैं। नीचे दिए गए उदाहरण काल्पनिक हैं।
curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
--header 'Content-Type: application/json' \
--data @proof-request.json \
https://api.multitel.net/v3/create_proof{
"entity_type": "identities",
"entity_id": "33333333333333333333333333333333",
"proof_type_id": "11111111111111111111111111111111",
"encrypted_file_ids": [
"22222222222222222222222222222222"
]
}| फ़ील्ड | अर्थ |
|---|---|
entity_type | identities या addresses का उपयोग करें। ऐसी श्रेणी चुनें जो आपकी लक्षित पहचान या पते और अपलोड की गई फ़ाइलों, दोनों से मेल खाती हो। |
entity_id | आपके खाते के स्वामित्व वाली पहचान या पते का पहचानकर्ता। अपने दस्तावेज़ कार्यप्रवाह से मिले पहचानकर्ता का उपयोग करें; उसकी जगह फ़ोन नंबर या किसी असंबंधित दस्तावेज़ का पहचानकर्ता न दें। |
proof_type_id | चयनित प्रमाण प्रकार का पहचानकर्ता। इसे अपलोड और आवश्यकता के अनुरूप रखें। |
encrypted_file_ids | फ़ाइल पहचानकर्ताओं की गैर-रिक्त JSON सरणी, जिसके पहचानकर्ता create_encrypt_files से मिलते हैं। फ़ाइलें उसी खाते की होनी चाहिए, उनकी वैधता समाप्त नहीं हुई होनी चाहिए और वे इकाई की श्रेणी से मेल खानी चाहिए। यह स्थानीय फ़ाइल पथों की सूची नहीं है। |
फ़ॉर्म डेटा भी स्वीकार किया जाता है, जिसमें बार-बार यह फ़ील्ड दिया जाता है: encrypted_file_ids[]। वास्तविक JSON सरणी या फ़ॉर्म सरणी को प्राथमिकता दें; JSON में एन्कोड की गई सरणी को सामान्य अदिश फ़ॉर्म मान के रूप में न भेजें।
प्रमाण का पहचानकर्ता सहेजकर रखें
{
"status": {
"code": 200,
"msg": "Proof created successfully."
},
"response": {
"id": "44444444444444444444444444444444",
"entity_type": "identities",
"entity_id": "33333333333333333333333333333333",
"proof_type_id": "11111111111111111111111111111111",
"proof_type_name": "Example identity proof"
}
}सफल प्रतिक्रिया पुष्टि करती है कि प्रमाण का संबंध बना दिया गया है। इससे पहचान/पते की स्वीकृति, देश की सभी आवश्यकताओं के सत्यापन या किसी टेलीफ़ोन नंबर के सक्रिय होने की पुष्टि नहीं होती।
त्रुटियाँ और वैधता समाप्त हो चुके अपलोड
API कोड 500 का उपयोग आवश्यक इनपुट न मिलने, दूरसंचार सेवा प्रदाता की विफलताओं और उसकी अमान्य प्रतिक्रिया के लिए होता है। कोड 404 का उपयोग तब होता है जब लक्षित पहचान या पता वर्तमान खाते से जुड़ा न हो, प्रमाण प्रकार अमान्य हो, इस खाते/श्रेणी के लिए कोई अपलोड की गई फ़ाइल न मिले या उसकी वैधता समाप्त हो गई हो, अथवा कोई उपयोग योग्य फ़ाइल पहचानकर्ता शेष न हो। status.msg को भी कोड के साथ पढ़ें।
जिस आवश्यक फ़ाइल की वैधता समाप्त हो गई है, उसे संलग्न करने से पहले सही प्रमाण श्रेणी का उपयोग करके दोबारा अपलोड करें। यदि दी गई कोई भी फ़ाइल अमान्य है, तो यह हैंडलर प्रमाण बनाने का अनुरोध भेजने से पहले ही रुक जाता है। दोहराए गए अनुरोधों से एक ही परिणाम सुनिश्चित करने वाली कोई कुंजी उपलब्ध नहीं कराई गई है: समय सीमा समाप्त होने के बाद दोबारा संलग्न करने से पहले पोर्टल में मौजूदा दस्तावेज़ की जाँच करें।