प्रोग्रामेटिक रजिस्ट्रेशन: AI एजेंट्स के लिए KYC API

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 पर प्रकाशित है; नीचे दिए गए endpoint उसके विरुद्ध ऑडिट किए गए हैं।

बेस URL

इस गाइड के सभी endpoint auth होस्ट पर हैं:

https://apx.didit.me/auth/v2

यह सत्यापन API (https://verification.didit.me/v3) से अलग होस्ट है। auth होस्ट JWT एक्सेस token जारी करता है और एप्लिकेशन प्रबंधित करता है। सत्यापन होस्ट सत्र, AML, वर्कफ़्लो आदि चलाता है, और उसे इस फ़्लो से मिलने वाली लंबी-अवधि की api_key से प्रमाणित किया जाता है।

त्वरित शुरुआत

वास्तविक, जिस पर ईमेल पहुँच सके, ऐसा ईमेल पता इस्तेमाल करें। यह endpoint सत्यापन कोड सिंक्रोनस रूप से भेजता है, इसलिए आरक्षित टेस्ट डोमेन (@example.com, @example.org, @*.test, @*.example, @*.invalid) मेल डिलीवरी द्वारा अस्वीकार कर दिए जाते हैं और कॉल 500 लौटाती है। नीचे दिए गए you@yourdomain.com प्लेसहोल्डर की जगह ऐसा इनबॉक्स लगाएँ जिसे आप पढ़ सकें।

चरण 1: पंजीकरण

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):

{
  "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: कोड सत्यापित करें और क्रेडेंशियल प्राप्त करें

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):

{
  "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 हेडर में भेजें।

Token RS256-साइन किए गए JWT होते हैं। expires_in का डिफ़ॉल्ट 86400 सेकंड (24 घंटे) है। एक्सेस token केवल apx.didit.me/auth/v2 पर मैनेजमेंट endpoint के लिए ज़रूरी है; verification.didit.me/v3 पर सत्यापन API ट्रैफ़िक लंबी-अवधि की api_key से प्रमाणित होता है, JWT से नहीं।

चरण 3: API का उपयोग करें

curl https://verification.didit.me/v3/sessions/ \
  -H "x-api-key: sk_live_example_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

बाद के लॉगिन

किसी भी भविष्य की मशीन से, अपना ईमेल और पासवर्ड देकर नया JWT प्राप्त करें:

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 प्राप्त करें।

कंसोल में बनाए गए ईमेल/पासवर्ड खाते भी ईमेल सत्यापित होने के बाद 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/<slug>"}`
पुनर्प्राप्त किया गया है और अभी तक कोई साइन-इन विधि नहीं है	`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 के रिस्पॉन्स बॉडी का स्वरूप ऐसा होता है:

{ "detail": "Too many login attempts from this IP address. Please wait before trying again." }

सत्यापन API की रेट लिमिट (जैसे 600 सत्र/मिनट) इनसे स्वतंत्र हैं और रेट लिमिटिंग में दस्तावेज़ित हैं।

एप्लिकेशन प्रबंधन

प्रमाणीकरण के बाद, आप अपने संगठन के भीतर एप्लिकेशन प्राप्त, बना या अपडेट कर सकते हैं। यह रीसेलर के लिए बिल्कुल उपयुक्त है जो हर ग्राहक के लिए एक एप्लिकेशन चाहते हैं। हर एप्लिकेशन का अपना client_id, api_key, मेटाडेटा और सेटिंग्स होते हैं। यह तब भी उपयोगी है जब आपके संगठन में अलग-अलग उत्पाद, ब्रांड, क्षेत्र, एनवायरनमेंट या उपयोग के मामले हों जिन्हें आप अलग रखना चाहते हैं।

# 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 संदर्भ देखें।

MCP सर्वर इंटीग्रेशन

सबसे अच्छा एजेंट अनुभव पाने के लिए, https://mcp.didit.me/mcp पर होस्टेड Didit MCP सर्वर का उपयोग करें। इसके लिए API कुंजी की ज़रूरत नहीं है: पहली बार कनेक्ट करने पर आपका क्लाइंट एक ब्राउज़र खोलता है, आप Didit के साथ लॉग इन करें विकल्प चुनते हैं (PKCE के साथ OAuth 2.1), और सर्वर आपकी कंसोल भूमिका की अनुमतियों के साथ आपकी ओर से काम करता है। जिन क्लाइंट में नेटिव रिमोट MCP सपोर्ट है (Cursor, VS Code), वे इस एंट्री का उपयोग करते हैं; Claude वेब और Desktop इसे कस्टम कनेक्टर के रूप में जोड़ते हैं:

{
  "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 अवलोकन और प्रति-क्लाइंट इंस्टॉलेशन देखें।

त्रुटि एनवेलप संदर्भ

सभी 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 शामिल होते हैं; देखें रेट लिमिटिंग।

गाइड

प्रमाणीकरण

Model Context Protocol (MCP)

वेब SDK

नेटिव SDK

सर्वर SDK

इंटीग्रेशन

प्रोग्रामेटिक रजिस्ट्रेशन: AI एजेंट्स के लिए KYC API

Overview

बेस URL

त्वरित शुरुआत

चरण 1: पंजीकरण

चरण 2: कोड सत्यापित करें और क्रेडेंशियल प्राप्त करें

चरण 3: API का उपयोग करें

बाद के लॉगिन

जब लॉगिन के लिए अतिरिक्त जानकारी माँगी जाए

पासवर्ड की आवश्यकताएँ

रेट लिमिट और लॉकआउट

एप्लिकेशन प्रबंधन

पंजीकरण के बाद एजेंट क्या कर सकते हैं?

MCP सर्वर इंटीग्रेशन

त्रुटि एनवेलप संदर्भ

​Overview

​बेस URL

​त्वरित शुरुआत

​चरण 1: पंजीकरण

​चरण 2: कोड सत्यापित करें और क्रेडेंशियल प्राप्त करें

​चरण 3: API का उपयोग करें

​बाद के लॉगिन

​जब लॉगिन के लिए अतिरिक्त जानकारी माँगी जाए

​पासवर्ड की आवश्यकताएँ

​रेट लिमिट और लॉकआउट

​एप्लिकेशन प्रबंधन

​पंजीकरण के बाद एजेंट क्या कर सकते हैं?

​MCP सर्वर इंटीग्रेशन

​त्रुटि एनवेलप संदर्भ

Overview

बेस URL

त्वरित शुरुआत

चरण 1: पंजीकरण

चरण 2: कोड सत्यापित करें और क्रेडेंशियल प्राप्त करें

चरण 3: API का उपयोग करें

बाद के लॉगिन

जब लॉगिन के लिए अतिरिक्त जानकारी माँगी जाए

पासवर्ड की आवश्यकताएँ

रेट लिमिट और लॉकआउट

एप्लिकेशन प्रबंधन

पंजीकरण के बाद एजेंट क्या कर सकते हैं?

MCP सर्वर इंटीग्रेशन

त्रुटि एनवेलप संदर्भ