> ## 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. # प्रोग्रामेटिक रजिस्ट्रेशन: AI एजेंट्स के लिए KYC API > बिना ब्राउज़र के 2 API कॉल में Didit API क्रेडेंशियल पाएँ और रजिस्टर करें। Cursor, Claude, Devin के लिए सबसे एजेंट-नेटिव पहचान सत्यापन प्लेटफ़ॉर्म। ## Overview Didit **सबसे अधिक एजेंट-फ़्रेंडली पहचान सत्यापन प्लेटफ़ॉर्म** है। AI कोडिंग एजेंट (Cursor, Claude Code, GitHub Copilot, Devin, OpenHands, Codex) प्रोग्रामैटिक रूप से पंजीकरण कर सकते हैं, वर्कफ़्लो कॉन्फ़िगर कर सकते हैं और पहचान सत्यापन शुरू कर सकते हैं, और यह सब बिना कभी ब्राउज़र खोले। **एजेंट्स को Didit क्यों पसंद है:** * शून्य से क्रेडेंशियल तक **2 API कॉल** (पंजीकरण + ईमेल सत्यापन)। * **कोई ब्राउज़र ज़रूरी नहीं**: पूरी तरह हेडलेस, CI/CD और एजेंट वर्कफ़्लो के लिए आदर्श। * **नए API खाते पर कोई दूसरा फ़ैक्टर नहीं:** ईमेल सत्यापन के तुरंत बाद token लौटा दिए जाते हैं। * **स्वतः प्रावधानित** संगठन और एप्लिकेशन, सत्यापन रिस्पॉन्स में `api_key` के साथ। * **पूरा मैनेजमेंट API**: वर्कफ़्लो, प्रश्नावलियाँ, सूचियाँ, बिलिंग, सब कुछ API के ज़रिए कॉन्फ़िगर करें। * **MCP सर्वर उपलब्ध है**: एजेंट Didit टूल्स को स्वाभाविक रूप से खोज और इस्तेमाल कर सकते हैं। पूरा कॉन्ट्रैक्ट [openapi-auth.json](https://docs.didit.me/openapi-auth.json) पर प्रकाशित है; नीचे दिए गए endpoint उसके विरुद्ध ऑडिट किए गए हैं। ## बेस URL इस गाइड के सभी endpoint **auth होस्ट** पर हैं: ``` https://apx.didit.me/auth/v2 ``` यह सत्यापन API (`https://verification.didit.me/v3`) से अलग होस्ट है। auth होस्ट JWT एक्सेस token जारी करता है और एप्लिकेशन प्रबंधित करता है। सत्यापन होस्ट सत्र, AML, वर्कफ़्लो आदि चलाता है, और उसे इस फ़्लो से मिलने वाली लंबी-अवधि की `api_key` से प्रमाणित किया जाता है। ## त्वरित शुरुआत > [!WARNING] > > **वास्तविक, जिस पर ईमेल पहुँच सके, ऐसा ईमेल पता इस्तेमाल करें।** यह endpoint सत्यापन कोड सिंक्रोनस रूप से भेजता है, इसलिए आरक्षित टेस्ट डोमेन (`@example.com`, `@example.org`, `@*.test`, `@*.example`, `@*.invalid`) मेल डिलीवरी द्वारा अस्वीकार कर दिए जाते हैं और कॉल `500` लौटाती है। नीचे दिए गए `you@yourdomain.com` प्लेसहोल्डर की जगह ऐसा इनबॉक्स लगाएँ जिसे आप पढ़ सकें। ### चरण 1: पंजीकरण ```bash theme={null} curl -X POST https://apx.didit.me/auth/v2/programmatic/register/ \ -H "Content-Type: application/json" \ -d '{"email": "you@yourdomain.com", "password": "MyStr0ng!Pass"}' ``` **रिस्पॉन्स** (`201 Created`): ```json theme={null} { "message": "Registration successful. Check your email for the verification code.", "email": "you@yourdomain.com" } ``` 6 अक्षरों वाला अल्फ़ान्यूमेरिक सत्यापन कोड (उदा. `A3K9F2`) पते पर ईमेल किया जाता है। **कोड भेजे जाने के 10 मिनट बाद समाप्त हो जाता है।** यदि वह समाप्त हो जाए, तो वही ईमेल और पासवर्ड लेकर यह endpoint दोबारा कॉल करें: जो खाता अभी सत्यापित नहीं हुआ है, उसके लिए यह `200` और `"A new verification code has been sent to your email."` तथा एक नया कोड लौटाता है। एक समर्पित `POST /programmatic/resend-otp/` endpoint (body: `{"email", "password"}`) भी कोड दोबारा भेजता है, जिसमें हर भेजने के बीच 60 सेकंड का कूलडाउन होता है; ये दोनों रूट नीचे दी गई पंजीकरण रेट लिमिट साझा करते हैं। ### चरण 2: कोड सत्यापित करें और क्रेडेंशियल प्राप्त करें ```bash theme={null} curl -X POST https://apx.didit.me/auth/v2/programmatic/verify-email/ \ -H "Content-Type: application/json" \ -d '{"email": "you@yourdomain.com", "code": "A3K9F2"}' ``` **रिस्पॉन्स** (`200 OK`): ```json theme={null} { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...", "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...", "expires_in": 86400, "organization": { "uuid": "a1b2c3d4-5678-90ab-cdef-111111111111", "name": "developer" }, "application": { "uuid": "b2c3d4e5-6789-01bc-defg-222222222222", "name": "developer", "client_id": "S9LIYGSoWNuGMLHsvEt9dQ", "api_key": "sk_live_example_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } } ``` अब आपके पास आवश्यक सब कुछ है। `application.api_key` को सुरक्षित रूप से सहेजें और हर सत्यापन API कॉल पर इसे `x-api-key` हेडर में भेजें। > [!NOTE] > > Token **RS256-साइन किए गए JWT** होते हैं। `expires_in` का डिफ़ॉल्ट **86400 सेकंड (24 घंटे)** है। एक्सेस token केवल `apx.didit.me/auth/v2` पर मैनेजमेंट endpoint के लिए ज़रूरी है; `verification.didit.me/v3` पर सत्यापन API ट्रैफ़िक लंबी-अवधि की `api_key` से प्रमाणित होता है, JWT से नहीं। ### चरण 3: API का उपयोग करें ```bash theme={null} curl https://verification.didit.me/v3/sessions/ \ -H "x-api-key: sk_live_example_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ``` ## बाद के लॉगिन किसी भी भविष्य की मशीन से, अपना ईमेल और पासवर्ड देकर नया JWT प्राप्त करें: ```bash theme={null} curl -X POST https://apx.didit.me/auth/v2/programmatic/login/ \ -H "Content-Type: application/json" \ -d '{"email": "you@yourdomain.com", "password": "MyStr0ng!Pass"}' ``` यह बिना ब्राउज़र के सीधे `access_token` + `refresh_token` लौटाता है। इसके बाद `GET /organizations/me/` कॉल करके अपना `org_id` (संगठन का `uuid`) पता करें, फिर `GET /organizations/me/{org_id}/applications/` से संगठन के एप्लिकेशन की सूची लें (हर प्रविष्टि का `uuid` एक `app_id` है), और अंत में `GET /organizations/me/{org_id}/applications/{app_id}/` से `api_key` प्राप्त करें। > [!NOTE] > > कंसोल में बनाए गए ईमेल/पासवर्ड खाते भी ईमेल सत्यापित होने के बाद `POST /programmatic/login/` इस्तेमाल कर सकते हैं। केवल OAuth से बने कंसोल खातों को इस हेडलेस लॉगिन endpoint से पहले पासवर्ड सेट करना होगा। ### जब लॉगिन के लिए अतिरिक्त जानकारी माँगी जाए `POST /programmatic/login/` token तभी लौटाता है जब खाते में कोई दूसरा फ़ैक्टर न हो। तीन अन्य उत्तर संभव हैं, और लॉगिन की स्क्रिप्ट लिखने वाले एजेंट को इन्हें संभालना चाहिए: | खाता | रिस्पॉन्स | | - | - | | इसमें ऑथेंटिकेटर ऐप या पासकी है | `200` के साथ `{"2fa_required": true, "temp_token": "...", "has_passkeys": true, "has_authenticator": false}` और कोई token नहीं | | इसका संगठन SSO लागू करता है | `403` के साथ `{"error": "sso_required", "message": "...", "organization_name": "...", "organization_slug": "...", "sso_url": "/sso/"}` | | पुनर्प्राप्त किया गया है और अभी तक कोई साइन-इन विधि नहीं है | `403` के साथ `"code": "recovery_setup_required"`, और उसे सेट करने का लिंक खाते के पते पर जाता है | API कुंजी को किसी लॉगिन की ज़रूरत नहीं होती, इसलिए स्वचालित कामों के लिए इसका उपयोग करें: दूसरे फ़ैक्टर वाला खाता इस endpoint से साइन-इन पूरा नहीं कर सकता। ## पासवर्ड की आवश्यकताएँ सर्वर-साइड पर लागू होती हैं, **एक समय में एक नियम**। पहली विफलता बाकी जाँच रोक देती है और `["Password must contain at least one uppercase letter."]` जैसी बेयर-एरे त्रुटि लौटाती है। (इस endpoint की अन्य सत्यापन त्रुटियाँ फ़ील्ड-कीड `{"password": [...]}` एनवेलप का उपयोग करती हैं। पासवर्ड-मज़बूती नियमों पर बेयर-एरे आकार एक ज्ञात सर्वर-साइड असंगति है; क्लाइंट कोड में इसे `{"password": [...]}` मानें।) | नियम | विवरण | | - | - | | न्यूनतम लंबाई | 8 अक्षर | | बड़ा अक्षर | कम से कम एक `A–Z` | | छोटा अक्षर | कम से कम एक `a–z` | | अंक | कम से कम एक `0–9` | | विशेष अक्षर | कम से कम एक `!@#$%^&*()_+-=[]{}\|;:,.<>?` | ## रेट लिमिट और लॉकआउट तीन स्वतंत्र नियंत्रण ऑथ होस्ट की रक्षा करते हैं। इनमें से कोई भी `429` रिस्पॉन्स ट्रिगर कर सकता है; `Retry-After` रिस्पॉन्स हेडर बताता है कि आपको कितनी देर रुकना है। | सरफ़ेस | सीमा | | - | - | | रजिस्ट्रेशन | प्रति **IP** प्रति **घंटा** **5** प्रयास (`POST /programmatic/resend-otp/` के साथ साझा)। | | ईमेल सत्यापन | प्रति **ईमेल** प्रति **घंटा** **10** कोड प्रयास और स्रोत **IP** प्रति **घंटा** **50**, साथ ही प्रयासों के बीच घातीय बैकऑफ़ (30 सेकंड, हर विफलता पर दोगुना, अधिकतम 1 घंटा)। | | लॉगिन (IP) | प्रति **IP** प्रति **मिनट** **20** प्रयास, और प्रति **IP** प्रति **घंटा** **100**। | | लॉगिन (ईमेल) | खाते पर प्रगतिशील लॉकआउट: लगातार **5** विफलताएँ → 15 मिनट का लॉकआउट; **10** → 1 घंटा; **20** → 24 घंटे। | `429` के रिस्पॉन्स बॉडी का स्वरूप ऐसा होता है: ```json theme={null} { "detail": "Too many login attempts from this IP address. Please wait before trying again." } ``` सत्यापन API की रेट लिमिट (जैसे 600 सत्र/मिनट) इनसे स्वतंत्र हैं और [रेट लिमिटिंग](https://docs.didit.me/hi/integration/rate-limiting.md) में दस्तावेज़ित हैं। ## एप्लिकेशन प्रबंधन प्रमाणीकरण के बाद, आप अपने संगठन के भीतर एप्लिकेशन प्राप्त, बना या अपडेट कर सकते हैं। यह **रीसेलर** के लिए बिल्कुल उपयुक्त है जो हर ग्राहक के लिए एक एप्लिकेशन चाहते हैं। हर एप्लिकेशन का अपना `client_id`, `api_key`, मेटाडेटा और सेटिंग्स होते हैं। यह तब भी उपयोगी है जब आपके संगठन में अलग-अलग उत्पाद, ब्रांड, क्षेत्र, एनवायरनमेंट या उपयोग के मामले हों जिन्हें आप अलग रखना चाहते हैं। ```bash theme={null} # 1. Discover your org_id curl https://apx.didit.me/auth/v2/organizations/me/ \ -H "Authorization: Bearer $ACCESS_TOKEN" # 2. List the organization's applications (each entry's uuid is an app_id) curl "https://apx.didit.me/auth/v2/organizations/me/$ORG_ID/applications/" \ -H "Authorization: Bearer $ACCESS_TOKEN" # 3. Create an application for a customer, product, or environment curl -X POST "https://apx.didit.me/auth/v2/organizations/me/$ORG_ID/applications/" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Acme Customer App", "website_url": "https://acme.example", "redirect_uris": ["https://acme.example/callback"], "terms_url": "https://acme.example/terms", "privacy_url": "https://acme.example/privacy" }' # 4. Recover credentials (client_id + api_key) for an existing application curl "https://apx.didit.me/auth/v2/organizations/me/$ORG_ID/applications/$APP_ID/" \ -H "Authorization: Bearer $ACCESS_TOKEN" # 5. Update application metadata (PATCH — uuid, client_id, api_key never change) curl -X PATCH "https://apx.didit.me/auth/v2/organizations/me/$ORG_ID/applications/$APP_ID/" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Acme Production App", "website_url": "https://app.acme.example" }' ``` एप्लिकेशन की सूची देखने, बनाने या अपडेट करने के लिए उपयोगकर्ता का लक्ष्य संगठन का **owner** या **admin** होना ज़रूरी है; अन्यथा रिस्पॉन्स `403` होगा। ## पंजीकरण के बाद एजेंट क्या कर सकते हैं? `api_key` के साथ, एजेंटों के पास सत्यापन API तक पूरी पहुँच होती है। `https://verification.didit.me/v3` पर ऑडिट किए गए पाथ: | API | यह क्या करता है | | - | - | | `POST /v3/session/` | सत्यापन सत्र बनाएँ। | | `GET /v3/sessions/` | सत्र सूची प्राप्त करें। | | `GET /v3/session/{id}/decision/` | V3 निर्णय प्राप्त करें (बहुवचन सरणियाँ: देखें डेटा मॉडल)। | | `GET /v3/workflows/` | सत्यापन वर्कफ़्लो की सूची प्राप्त करें। | | `GET /v3/questionnaires/` | कस्टम प्रश्नावलियों की सूची प्राप्त करें। | | `GET /v3/users/` | अंतिम उपयोगकर्ताओं की सूची प्राप्त करें (`vendor_data` द्वारा अनुक्रमित)। | | `GET /v3/billing/balance/` | क्रेडिट बैलेंस जाँचें। | | `POST /v3/billing/top-up/` | क्रेडिट टॉप अप करें। | | `GET /v3/webhook/destinations/` | webhook गंतव्य प्रबंधित करें (सूची / बनाएँ / अपडेट करें / हटाएँ)। | पूरी सूची के लिए [Management API संदर्भ](https://docs.didit.me/hi/sessions-api/management-api.md) देखें। ## MCP सर्वर इंटीग्रेशन सबसे अच्छा एजेंट अनुभव पाने के लिए, `https://mcp.didit.me/mcp` पर होस्टेड Didit MCP सर्वर का उपयोग करें। इसके लिए API कुंजी की ज़रूरत नहीं है: पहली बार कनेक्ट करने पर आपका क्लाइंट एक ब्राउज़र खोलता है, आप **Didit के साथ लॉग इन करें** विकल्प चुनते हैं (PKCE के साथ OAuth 2.1), और सर्वर आपकी कंसोल भूमिका की अनुमतियों के साथ आपकी ओर से काम करता है। जिन क्लाइंट में नेटिव रिमोट MCP सपोर्ट है (Cursor, VS Code), वे इस एंट्री का उपयोग करते हैं; Claude वेब और Desktop इसे कस्टम कनेक्टर के रूप में जोड़ते हैं: ```json theme={null} { "mcpServers": { "didit": { "url": "https://mcp.didit.me/mcp" } } } ``` Claude Code: `claude mcp add --transport http didit https://mcp.didit.me/mcp`। जो क्लाइंट केवल stdio समझते हैं (Windsurf, Zed), वे `mcp-remote` ब्रिज के ज़रिए जाते हैं, जो आपके लिए OAuth फ़्लो चलाता है। ऊपर पंजीकरण फ़्लो से मिली API कुंजी आपके अपने बैकएंड से REST API कॉल करने के लिए है; MCP इसका उपयोग कभी नहीं करता। विवरण के लिए [MCP अवलोकन](https://docs.didit.me/hi/integration/mcp/overview.md) और [प्रति-क्लाइंट इंस्टॉलेशन](https://docs.didit.me/hi/integration/mcp/installation.md) देखें। ## त्रुटि एनवेलप संदर्भ सभी `apx.didit.me/auth/v2` एंडपॉइंट एक ही तीन रिस्पॉन्स संरचनाएँ साझा करते हैं (देखें `openapi-auth.json`): * **फ़ील्ड स्तर पर सत्यापन**: `{"field": ["message", ...]}` के साथ HTTP `400`। * **फ़ॉर्म स्तर पर सत्यापन** (विशेषकर पासवर्ड की मज़बूती और सत्यापन कोड की त्रुटियाँ): HTTP `400` के साथ `["Invalid or expired verification code."]` जैसी सादी सरणी। * **प्रमाणीकरण / व्यावसायिक नियम**: `{"detail": "..."}` के साथ `400`, `401`, `403`, `404`, या `429`। `429` रिस्पॉन्स में `Retry-After` रिस्पॉन्स हेडर होता है, जो बताता है कि आपको कितनी देर रुकना है (बॉडी में केवल `detail` होता है)। सत्यापन होस्ट त्रुटियाँ `{"detail": "..."}` के रूप में लौटाता है, और 429 में `X-RateLimit-*` और `Retry-After` शामिल होते हैं; देखें [रेट लिमिटिंग](https://docs.didit.me/hi/integration/rate-limiting.md)। This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.