> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# ग्राहक संदेश: पूर्व-निर्धारित संदेश और जवाब

> Didit के ग्राहक संदेश में पूर्व-निर्धारित संदेश देखें, सत्यापित संपर्क से जानकारी माँगें और ग्राहकों के जवाबों की समीक्षा करें।

केस खोलें और **ग्राहक को संदेश भेजें** चुनें।
एक सत्यापित प्राप्तकर्ता, भाषा और उद्देश्य चुनें, फिर **पूर्वावलोकन** चुनें।
पूर्वावलोकन में सटीक प्रेषक, प्राप्तकर्ता, विषय और ईमेल का मुख्य भाग दिखता है।
चयन बदलने के लिए **संपादित करें** चुनें, या चयन की पुष्टि के लिए **भेजें** चुनें।
बदला गया या जिसकी समय-सीमा समाप्त हो गई हो ऐसा पूर्वावलोकन भेजने से पहले फिर से बनाना होगा।

## संदेश के उद्देश्य

| उद्देश्य | ग्राहक की कार्रवाई | केस की स्थिति |
| - | - | - |
| पहचान दस्तावेज़ | पहचान दस्तावेज़ की एक स्पष्ट फ़ोटो अपलोड करें | उपयोगकर्ता की प्रतीक्षा में |
| पते का प्रमाण | नाम और निवास पता दिखाने वाला हाल का दस्तावेज़ अपलोड करें | उपयोगकर्ता की प्रतीक्षा में |
| व्यवसाय दस्तावेज़ | व्यवसाय पंजीकरण दस्तावेज़ अपलोड करें | उपयोगकर्ता की प्रतीक्षा में |
| विवरण की पुष्टि | समीक्षक के मूल्यांकन के लिए पूरा नाम और जन्म तिथि भेजें | उपयोगकर्ता की प्रतीक्षा में |
| समीक्षा जारी | कोई कार्रवाई आवश्यक नहीं; ईमेल में कोई प्रतिक्रिया बटन नहीं होता | अपरिवर्तित |

फ़िलहाल दस्तावेज़ अपलोड में 5 MB तक की JPEG, PNG और WebP इमेज स्वीकार की जाती हैं।
केवल वही उद्देश्य दिखते हैं जो केस के विषय पर लागू होते हैं।
ग्राहक के ईमेल टेम्पलेट फ़िलहाल अंग्रेज़ी, स्पेनिश और पुर्तगाली में उपलब्ध हैं।
कंसोल वही ईमेल फ़ील्ड और भाषा चयनकर्ता इस्तेमाल करता है जो सत्र पुनः सबमिट करने में होता है।

## सत्यापित प्राप्तकर्ता और निश्चित टेम्पलेट

प्राप्तकर्ता के पास केस के विषय और एप्लिकेशन से जुड़े सत्र में ईमेल सत्यापन पूरा हो चुका होना चाहिए।
उपयोगकर्ता प्रोफ़ाइल में आयात किया गया या संपादित किया गया पता सत्यापन स्थापित नहीं करता।
यदि कोई सत्यापित संपर्क नहीं है, तो कंपोज़र यह समझाता है और भेजना अक्षम रहता है।

समीक्षक मनमाना ईमेल टेक्स्ट, लिंक, प्रेषक पते या प्राप्तकर्ता नहीं दे सकते।
ईमेल में मौजूदा Didit या व्हाइट लेबल ब्रांडिंग इस्तेमाल होती है।
कस्टम प्रेषक के लिए कॉन्फ़िगर किए गए ईमेल डोमेन का सत्यापित होना आवश्यक है।
हर टेम्पलेट प्राप्तकर्ता को बताता है कि ईमेल पासवर्ड, सत्यापन कोड या भुगतान नहीं मांगेगा।

सत्र पुनः सबमिट करना सत्यापन जाँचों को दोहराने के लिए एक अलग कार्रवाई बनी रहती है।
इसका पूर्वावलोकन वास्तविक पुनः सबमिशन ईमेल और चुनी गई जाँचें दिखाता है।

## डिलीवरी और प्रतिक्रियाएँ

संदेश इतिहास में कतार में, भेजा जा रहा, भेजा गया, सिमुलेटेड और अज्ञात डिलीवरी परिणाम अलग-अलग दिखाए जाते हैं।
सिमुलेटेड ईमेल नहीं भेजा जाता।
अज्ञात परिणाम का अर्थ है कि प्रदाता ने ईमेल स्वीकार कर लिया हो सकता है; सिस्टम उसे अपने-आप दोबारा नहीं भेजता।
पुष्ट अनुरोध को पुनः प्रयास करने पर डुप्लिकेट डिलीवरी से बचने के लिए वही request ID इस्तेमाल होता है।

कार्रवाई योग्य अनुरोध में सात दिनों तक मान्य एक सुरक्षित प्रतिक्रिया लिंक होता है।
अनुरोध रद्द करने या केस का समाधान करने पर वह लिंक अमान्य हो जाता है, यहाँ तक कि केस दोबारा खोले जाने के बाद भी।
ग्राहक पेज केस के निजी निष्कर्ष या अन्य स्रोत रिकॉर्ड प्रकट नहीं करता।

सबमिट की गई प्रतिक्रिया **ग्राहक संदेश** में समीक्षा के लिए लंबित साक्ष्य के रूप में दिखती है।
केस की स्थिति फिर से खुली हो जाती है, और मौजूदा लंबित समाधान की फिर से समीक्षा करनी होगी।
प्रतिक्रियाएँ पहले की सबमिशन की जगह नहीं ले सकतीं, मूल सत्यापन को स्वीकृत नहीं कर सकतीं, ग्राहक की पहचान को अधिलेखित नहीं कर सकतीं या धोखाधड़ी परिणाम में योगदान नहीं दे सकतीं।

स्रोत सत्यापन या केस हटाने पर उसके ग्राहक अनुरोध और उनके अपलोड किए गए साक्ष्य भी हटा दिए जाते हैं।

## API वर्कफ़्लो

कंसोल के सभी endpoint एक संगठन, एप्लिकेशन और केस तक सीमित हैं:

```text theme={null}
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/options/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/preview/
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/cancel/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/remind/
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/attachment/
```

इतिहास और अटैचमेंट पढ़ने के लिए `read:cases` आवश्यक है।
कंपोज़ करने, पूर्वावलोकन करने, पुष्टि करने, रद्द करने और अनुस्मारक भेजने के लिए `write:cases` आवश्यक है।
पुष्टि में वही `contact_id`, `purpose` और `language` होने चाहिए, साथ में पूर्वावलोकन द्वारा लौटाए गए `request_id`, `expires_at` और `preview_token` भी।
पुष्टि रसीद 15 मिनट बाद समाप्त हो जाती है, जो ग्राहक की प्रतिक्रिया की समय-सीमा से स्वतंत्र है।

अनुस्मारक वही ईमेल उसी सत्यापित प्राप्तकर्ता को फिर से भेजता है, प्रति अनुरोध हर 24 घंटे में अधिकतम एक बार।
इसके अलावा कुछ नहीं बदलता: अनुरोध की समय-सीमा वही रहती है और केस की स्थिति भी वही रहती है।
प्रतिक्रिया में अनुरोध, `reminded_at`, अनुस्मारक का अपना `delivery_status` (`SENT`, `SIMULATED` या `UNKNOWN`) और `next_reminder_at` लौटाए जाते हैं।
जिस अनुरोध का उत्तर ग्राहक को अब देना नहीं है, वह `409` के साथ `code` `case_request_not_waiting` और एक `reason` लौटाता है: `answered`, `cancelled`, `expired`, `closed`, `not_actionable`, `not_delivered` या `contact_unavailable`।
24 घंटों के भीतर दूसरा अनुस्मारक `429` लौटाता है, जिसके साथ `code` `case_request_reminder_too_soon`, एक `retry_at` टाइमस्टैम्प और एक `Retry-After` हेडर होता है।
जब कोई समाधान अनुमोदन की प्रतीक्षा में हो, तो अनुस्मारक `400` लौटाता है।

ग्राहक endpoint `GET` या `POST /v3/case-requests/{request_uuid}/` है, जिसके साथ उस अनुरोध-विशिष्ट `X-Case-Request-Token` हेडर का इस्तेमाल होता है।
प्रतिक्रिया लिंक यह क्रेडेंशियल अपने फ़्रैगमेंट में रखता है; पेज खुलते ही फ़्रैगमेंट हटा दिया जाता है।
यह token केवल उसी अनुरोध तक पहुँच देता है।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.