POST/api/public/access-request/email/start-verification

पहुँच अनुरोध गर्नु अघि पहिलो चरणमा, तपाईँले दिएको इमेल ठेगानामा १० मिनेटको लागि मान्य ६ अंकको कन्फर्मेसन कोड पठाउनुहोला ।

`POST /api/public/access-request/email/start-verification` ले सार्वजनिक पहुँच अनुरोधका लागि इमेल-प्रमाणीकरण सुरु गर्छ। यस Request लाई लगइन आवश्यक पर्दैन र Body-फिल्ड `email` मा जाँच गरिनुपर्ने ठेगाना समावेश हुन्छ। सफल प्रशोधन भएमा प्रणालीले दस मिनेटसम्म मान्य हुने छ-अंकको पुष्टि कोड पठाउँछ। प्रतिक्रियामा `ok`, एउटा `verification_id`, `expires_in_minutes` र `resend_cooldown_seconds` समावेश हुन्छन्। `verification_id` लाई त्यही इमेल ठेगाना र प्राप्त कोडसँगै पछिको Verify-रूटमा प्रयोग गर्नुपर्छ। यो Login-Token होइन र यसलाई स्थायी प्रयोगकर्ता पहिचानका रूपमा भण्डारण वा सार्वजनिक रूपमा लग गर्नु हुँदैन। यो एन्डपोइन्ट आइडेम्पोटेन्ट होइन। धेरै सफल कलले धेरै प्रमाणीकरण प्रक्रिया अथवा नयाँ कोडहरू उत्पन्न गर्न सक्छन्। त्यसैले IP-आधारित कडा सीमा 15 मिनेटभित्र दस अनुरोध लागू हुन्छ। साथै, प्रतिक्रियाले 60 सेकेन्डको पुनःपठाउने रोकको संकेत गर्छ। यस अवधिमा इन्टरफेसले फेरि पठाउने कार्य सुरु गर्नु हुँदैन र बाँकी पर्खने समय बुझ्न सकिने तरिकाले देखाउनुपर्छ। सीमा नाघेमा रूटले `429 RATE_LIMIT_EXCEEDED` सँग प्रतिक्रिया दिन्छ। ढुवानी त्रुटिका कारण कोड पठाउन नसकिएमा `502 MAIL_NOT_SENT` दस्ताबेजीकृत छ। यी दुई अवस्थालाई छुट्टाछुट्टै व्यवस्थापन गर्नुपर्छ: Rate-Limit पर्खेर समाधान गरिन्छ, इमेल त्रुटिलाई पहुँचयोग्य ठेगाना र कार्यरत डेलिभरी चाहिन्छ। त्रुटि सन्देशमा गोप्य जानकारी वा आन्तरिक मेलसर्भर विवरण राख्नु हुँदैन। सफल अवस्था वास्तविक `verification_id` सहित Live मा प्रमाणित गरिएको थियो। सम्बन्धित सन्देश आफ्नै Fake-SMTP सर्भरमार्फत प्राप्त गरिएको थियो र छ-अंकको कोड वास्तविक इमेल सामग्रीबाट पढिएको थियो। साथै, बारम्बार कल गरेपछि 429 नकारात्मक अवस्था पनि अवलोकन गरिएको थियो। ठ्याक्कै यही प्रमाण मात्र उल्लेख गर्न सकिन्छ; यसबाट सफलतापूर्वक सम्पन्न भएको पहुँच अनुरोध वा भुक्तानी प्रक्रिया अझै निष्कर्षमा आउँदैन।

{"email":"max@example.com"}

{"ok":true,"verification_id":"<UUID>","expires_in_minutes":10,"resend_cooldown_seconds":60}