> ## 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.
# सत्र बनाएं API: KYC या KYB सत्यापन शुरू करें
> Didit का POST /v3/session/ सत्यापन सत्र शुरू करता है। एकीकृत KYC + KYB, प्रति उपयोग मूल्य निर्धारण, 2s से कम अनुमान, $10 मासिक निःशुल्क क्रेडिट।
सत्र बनाने का प्रॉम्प्ट
प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें
\
\`Create a verification session via Didit's REST API.
Endpoint:
POST https://verification.didit.me/v3/session/
Authentication:
Use the x-api-key header with your Didit API key. The workflow's type (KYC or KYB) determines which kind of session is created — there is no separate endpoint for KYB.
Request body:
\- workflow_id (string, UUID, required) — Stable workflow UUID from /v3/workflows/. KYC workflows create User Verification sessions; KYB workflows create Business Verification sessions.
\- vendor_data (string, optional) — Your stable identifier for the entity (user or business). Strongly recommended: it binds the session to a User or Business entity and is used for duplicate detection across sessions.
\- callback (string, URL, optional): Where the hosted flow redirects the user when finished. Didit appends ?verificationSessionId={session_id}&status={status}. Falls back to the workflow default. When the application has allowed domains (allowed_domains on PATCH /v3/webhook/), an http or https callback must be on one of those origins (same scheme, host and port), otherwise creation fails with 400 on callback: "callback must be on one of the application's allowed domains: https://app.example.com". Custom URL schemes (app deep links such as myapp://) are always accepted. A workflow-default callback outside the allowed domains is not used for the redirect.
\- callback_method (string, optional, default "initiator") — One of "initiator", "completer", "both". Use "both" if the callback sometimes fails to fire.
\- metadata (object, optional) — Arbitrary JSON echoed back in responses and webhooks. Not shown to the user.
\- tags (array of strings, optional): Tags added to the session when it is created, by name, for example ["VIP", "ONBOARDING Q4"]. Up to 10, each up to 50 characters. Names are case-insensitive and stored in upper case; a name that does not exist yet in the application is created as a new tag. The tags show on the session in the console, where you can filter by them, and come back in the create response.
\- language (string, optional) — ISO 639-1 code for the verification UI (en, es, fr, de, pt, etc.). Defaults to browser detection.
\- contact_details (object, optional) — { email, send_notification_emails, email_lang, phone }. Pre-fills phone/email steps and (optionally) sends notification emails.
\- expected_details (object, optional) — Expected first_name, last_name, date_of_birth, nationality (ISO-3), id_country (ISO-3), expected_document_types (e.g. ["P","ID","DL","RP","SSC"]). Mismatches surface as decision warnings. For Business Verification (KYB) workflows, pass the business fields instead — company_name, registry_country, registration_number — to pre-fill the company registry search; registry_country is ISO 3166-1 alpha-2 and can include the state for state-level registries (e.g. "US-CA"), same format as the KYB Registry Search country_code. Person-level fields are ignored on KYB sessions.
\- portrait_image (string, base64, conditional) — Reference face for Biometric Authentication workflows (and graph workflows where Face Match runs before ID Verification). Max 2MB; JPEG, PNG, WebP, or TIFF. Optional when the vendor_data user already has a stored face: Didit reuses it automatically (approved liveness face, then ePassport chip photo, then ID document portrait, then a manually enrolled profile face). If omitted and no stored face exists, creation fails with 400. Ignored for other workflow types.
\- multi_account_segment (string, optional, max 64 chars) — Duplicate-detection realm inside your own organization. Duplicate face checks only compare this session against other sessions carrying the same segment, so an organization that runs separate account bases (personal vs business, or one per sub-client) does not see a person who legitimately holds one account in each reported as a duplicate. Omit it to use the single default realm — which is what every session uses today, so existing integrations are unaffected. Blocklist and allowlist matching ignore this field: a blocklisted face stays blocklisted in every segment.
\- sandbox_scenario (string, optional, sandbox applications only): Scenario slug from the sandbox catalog (GET /v1/sandbox/scenarios/). Expands the scenario's bundled magic values onto contact_details/expected_details so the session reproduces that outcome. Rejected with 400 on live applications. You can also arm or re-arm a scenario after create, as long as the session is still Not Started, via POST /v3/session/{session_id}/sandbox/arm/. See /integration/sandbox-testing.
\- user_state (string, optional, max 16 chars): Where the person lives, when you know it: an ISO 3166-2 code (US-IL) or a US state code or name (IL, Illinois). In Auto consent mode, Illinois, Texas or Colorado makes the flow ask for explicit biometric consent before the first face capture. 400 on an unrecognized value.
\- biometric_consent (object, optional): Consent you already collected: { given_at (ISO 8601, not in the future), text_version (max 64 chars) }. The flow does not ask again; the decision records it as given with trigger customer_collected.
\- sign (object, optional): { documents: [ { title, file_name, content_base64, fields } ], field_values: { : value } }. documents is for a workflow whose E-signature step takes documents from the session (signature_documents_source "session" or "both"). file_name ends in .pdf or .docx; content_base64 is the file in base64. Up to 20 documents and 50 MB in total; a PDF up to 20 MB and 100 pages, without a password, scripts or attachments; a Word file (.docx) up to 20 MB, converted to PDF while the request runs, at most 5 per session. fields is optional (up to 200 per document): signature, initials, full_name, date_signed, text, checkbox, email or data fields, each with a key unique in its document (^[a-z][a-z0-9_]{0,63}$), placed by page, x, y, width and height, or by anchor text ({ text, occurrence, offset_x, offset_y, width, height }). role defaults to the step's signer. field_values fills the fields whose prefill is "api.", on workflow and session documents alike: strings of 1 to 500 characters, booleans for checkboxes. 400 when the workflow has no E-signature step, takes workflow documents only and you sent documents, or needs session documents you didn't send; field_anchor_not_found, field_value_unknown, field_value_missing or field_value_invalid for fields and values. See /core-technology/electronic-signature/overview.
Idempotency:
Within one application, only one non-finished session can exist per (workflow_id, vendor_data). Calling create again with the same pair returns the existing session (and updates its callback + metadata, and adds any tags you send) instead of creating a duplicate. If you send sign again, its documents, fields and field values must be identical (same order, titles, file names, content, fields and values), or the call returns 400 { "sign": "signature_document_changed" }.
curl example:
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{
"workflow_id": "",
"vendor_data": "user-42",
"callback": "https://yourapp.com/callback",
"metadata": { "plan": "premium" }
}'
Response (201 Created) — keys you must handle:
\- session_id (UUID) — use this on every subsequent /v3/session/{session_id}/... call.
\- session_kind ("user" | "business") — discriminator, dispatch on this.
\- session_number (int) — human-friendly per-application sequence.
\- session_token (string) — short-lived, embedded in the hosted URL. Treat as secret.
\- url (string) — hosted verification URL. Redirect the end user here. (Field name is "url", NOT "verification_url".)
\- status (string) — newly created sessions return "Not Started".
\- workflow_id, workflow_version, vendor_data, metadata, callback — echoed back.
See /reference/data-models for the full schema.
Failure modes:
\- 400 — { "workflow_id": ["Invalid workflow_id."] } when the UUID is unknown.
\- 400 — { "vendor_data": ["This user or business has been blocked and cannot create new verification sessions."] } when blocklisted.
\- 400 — { "detail": "You don't have enough credits to perform this request. Please top up at https://business.didit.me" } when out of credits.
\- 400 — { "portrait_image": "No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first." } on a Face Match workflow when portrait_image is omitted and the vendor_data user has no stored face.
\- 401 — invalid or missing API key.
\- 403 — { "detail": "You do not have permission to perform this action." } when the key lacks write:sessions.
\- 429 — rate limited (600 successful calls/minute per token/IP). Honour Retry-After.
Disclosure & consent:
This endpoint generates a URL — it does not record that you obtained user consent. Show your privacy notice and any biometric-specific consent in your own UX before redirecting to the hosted flow.
For people covered by Illinois, Texas or Colorado law, the hosted flow and native SDK 4.10.0 or later can ask for explicit biometric consent before the selfie; native SDKs below 4.10.0 cannot show that step. See /getting-started/biometric-consent.
Next step:
After the user finishes (status changes to Approved / Declined / In Review), call GET https://verification.didit.me/v3/session/{session_id}/decision/ for the full decision — see /sessions-api/retrieve-session.
For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`
\
यहाँ पेस्ट करें
## KYC और KYB सहायताएक ही एंडपॉइंट से उपयोगकर्ता सत्यापन और व्यवसाय सत्यापन, दोनों प्रकार के सत्र बनते हैं। **वर्कफ़्लो का प्रकार** तय करता है कि कौन-सा सत्र बनेगा:- **KYC वर्कफ़्लो** का `workflow_id` पास करें → उपयोगकर्ता सत्यापन (KYC) सत्र बनता है। रिस्पॉन्स में `session_kind: "user"` आता है।
- **KYB वर्कफ़्लो** का `workflow_id` पास करें → व्यवसाय सत्यापन (KYB) सत्र बनता है। रिस्पॉन्स में `session_kind: "business"` आता है।कंसोल में *Workflows → Create workflow* पर जाकर वर्कफ़्लो कॉन्फ़िगर करें। वर्कफ़्लो बनाते समय वह या तो KYC होता है या KYB; बाद में आप उसका प्रकार नहीं बदल सकते।## उदाहरण> [tab] उपयोगकर्ता सत्यापन (KYC)
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "workflow_id": "YOUR_KYC_WORKFLOW_ID",
> "vendor_data": "user-42",
> "callback": "https://yourapp.com/callback"
> }'
> ```
>
> **रिस्पॉन्स (201 Created):**
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
> "session_kind": "user",
> "session_number": 1024,
> "session_token": "...",
> "url": "https://verify.didit.me/session/...",
> "status": "Not Started",
> "workflow_id": "YOUR_KYC_WORKFLOW_ID",
> "vendor_data": "user-42"
> }
> ```> [tab] व्यवसाय सत्यापन (KYB)
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "workflow_id": "YOUR_KYB_WORKFLOW_ID",
> "vendor_data": "biz-acme-001",
> "callback": "https://yourapp.com/callback"
> }'
> ```
>
> **रिस्पॉन्स (201 Created):**
>
> ```json theme={null}
> {
> "session_id": "bs-01HJX1...",
> "session_kind": "business",
> "session_number": 89,
> "session_token": "...",
> "url": "https://verify.didit.me/session/...",
> "status": "Not Started",
> "workflow_id": "YOUR_KYB_WORKFLOW_ID",
> "vendor_data": "biz-acme-001"
> }
> ```## ई-हस्ताक्षर दस्तावेज़जब वर्कफ़्लो में कोई [ई-हस्ताक्षर](https://docs.didit.me/hi/core-technology/electronic-signature/overview.md) चरण हो जो सत्र से दस्तावेज़ लेता है (`signature_documents_source` को `session` या `both` पर सेट किया गया हो), तो उन्हें `sign.documents` में भेजें। हर दस्तावेज़ base64 में एन्कोड की गई फ़ाइल होता है, इसलिए Didit को कभी किसी URL से फ़ाइल लाने की ज़रूरत नहीं पड़ती।```json theme={null}
{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-42",
"sign": {
"documents": [
{
"title": "Loan agreement",
"file_name": "loan-agreement.pdf",
"content_base64": "JVBERi0xLjcKJc...",
"fields": [
{ "key": "borrower_signature", "type": "signature", "label": "Borrower signature", "page": 3, "x": 0.1, "y": 0.78, "width": 0.32, "height": 0.06 },
{ "key": "date_signed", "type": "date_signed", "label": "Date", "page": 3, "x": 0.6, "y": 0.8, "width": 0.2, "height": 0.03, "date_format": "DD/MM/YYYY" },
{ "key": "loan_amount", "type": "data", "label": "Loan amount", "page": 1, "x": 0.34, "y": 0.31, "width": 0.3, "height": 0.03, "prefill": "api.loan_amount" },
{ "key": "initials", "type": "initials", "anchor": { "text": "[[initials]]", "occurrence": "all", "offset_x": 0, "offset_y": -0.005, "width": 0.12, "height": 0.04 } }
]
}
],
"field_values": { "loan_amount": "12,000 EUR" }
}
}
```| फ़ील्ड | नियम |
| - | - |
| `title` | साइनर को दिखाया जाता है। 1 से 255 अक्षर। डिफ़ॉल्ट रूप से `file_name` लिया जाता है। |
| `file_name` | अनिवार्य। `.pdf` या `.docx` पर समाप्त होना चाहिए। 1 से 255 अक्षर। |
| `content_base64` | अनिवार्य। PDF में अधिकतम 20 MB और 100 पेज हो सकते हैं, बिना पासवर्ड, स्क्रिप्ट या संलग्न फ़ाइलों के। Word फ़ाइल अधिकतम 20 MB की हो सकती है और अनुरोध के दौरान PDF में बदली जाती है, जिसमें अधिकतम 25 सेकंड लगते हैं; उसके बाद PDF पर भी वही सीमाएँ लागू होती हैं। हर सत्र में अधिकतम 5 Word फ़ाइलें। |
| `fields` | वैकल्पिक। दस्तावेज़ पर रखे जाने वाले अधिकतम 200 [फ़ील्ड](https://docs.didit.me/hi/core-technology/electronic-signature/overview.md#दस्तावेज़-पर-फ़ील्ड), `id` के बिना फ़ील्ड के प्रारूप में। हर फ़ील्ड को `key` और `type` चाहिए, और या तो एक स्थिति (`page`, `x`, `y`, `width` और `height`) या एक [`anchor`](#एंकर-टेक्स्ट-से-फ़ील्ड-लगाएँ)। `role` डिफ़ॉल्ट रूप से चरण के साइनर का होता है, और `required` व `label` प्रकार से डिफ़ॉल्ट होते हैं। Didit `position` को फ़ील्ड की जगह से सेट करता है। पेज और स्थितियाँ PDF के संदर्भ में होती हैं, या Word फ़ाइल के मामले में बदली गई PDF के संदर्भ में। |`fields` के बिना, साइनर दस्तावेज़ पढ़कर उससे सहमति देता है।### एंकर टेक्स्ट से फ़ील्ड लगाएँस्थिति देने के बजाय, फ़ील्ड में `anchor` दिया जा सकता है: दस्तावेज़ में मौजूद एक टेक्स्ट जो बताता है कि फ़ील्ड कहाँ जाएगा। एंकर उन दस्तावेज़ों के लिए ठीक हैं जिन्हें हर सत्र के लिए बनाया जाता है, जैसे Word टेम्पलेट से। वर्कफ़्लो दस्तावेज़ों के लिए फ़ील्ड कंसोल में लगाएँ।| `anchor` प्रॉपर्टी | नियम |
| - | - |
| `text` | 1 से 64 अक्षर, जिन्हें दस्तावेज़ के टेक्स्ट में खोजा जाता है। Word फ़ाइल के लिए, बदली गई PDF में। |
| `occurrence` | `first` (डिफ़ॉल्ट) पहले मिलान पर एक फ़ील्ड लगाता है। `all` हर मिलान पर एक फ़ील्ड लगाता है, और पहले के बाद वाली keys को `_2`, `_3` आदि मिलते हैं। |
| `offset_x`, `offset_y` | पेज के अंश। फ़ील्ड का ऊपर-बायाँ कोना, एंकर टेक्स्ट के ऊपर-बाएँ कोने में इन ऑफ़सेट को जोड़कर बनता है। |
| `width`, `height` | फ़ील्ड का आकार, पेज के अंश के रूप में। |जब टेक्स्ट दस्तावेज़ में नहीं मिलता, तो कॉल `400` के साथ `field_anchor_not_found` और फ़ील्ड की key लौटाती है। Didit PDF से एंकर टेक्स्ट नहीं हटाता, इसलिए उसे पेज के बैकग्राउंड जैसे रंग में लिखें।### फ़ील्ड मान`sign.field_values` हर उस फ़ील्ड का मान सेट करता है जिसका `prefill` `api.` है, चाहे वह वर्कफ़्लो दस्तावेज़ पर हो या सत्र दस्तावेज़ पर। यह एक ऑब्जेक्ट है, जिसकी keys ये `` नाम होते हैं। `text` और `data` फ़ील्ड के लिए मान 1 से 500 अक्षरों की स्ट्रिंग होते हैं, और `checkbox` के लिए बूलियन।```json theme={null}
{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-42",
"sign": {
"field_values": { "credit_limit": "3,000 EUR", "monthly_fee": "4.90 EUR" }
}
}
```| त्रुटि (`400`) | कब |
| - | - |
| `field_value_unknown` | ऐसी key जिसका कोई फ़ील्ड उपयोग नहीं करता। |
| `field_value_missing` | एक अनिवार्य फ़ील्ड जिसके `api.` का कोई मान नहीं है। |
| `field_value_invalid` | ऐसा मान जो अपने फ़ील्ड के [वैलिडेशन](https://docs.didit.me/hi/core-technology/electronic-signature/overview.md#सत्यापन) में असफल होता है। |### त्रुटियाँ और दोहराई गई कॉलएक सत्र में कुल मिलाकर अधिकतम 20 दस्तावेज़ और 50 MB हो सकते हैं। कॉल `sign` त्रुटि के साथ `400` लौटाती है जब:- वर्कफ़्लो में कोई ई-हस्ताक्षर चरण नहीं है।
- आपने `sign.documents` भेजा, जबकि चरण केवल वर्कफ़्लो दस्तावेज़ लेता है।
- चरण केवल सत्र दस्तावेज़ लेता है और आपने कोई नहीं भेजा, या उसमें वर्कफ़्लो दस्तावेज़ नहीं हैं और आपने कोई नहीं भेजा।
- कोई दस्तावेज़ बहुत बड़ा है, वैध base64 नहीं है, या समर्थित फ़ाइल नहीं है।
- कोई Word फ़ाइल `signature_document_not_supported` के साथ अस्वीकार हो जाती है, या बदली नहीं जा सकती और `signature_document_conversion_failed` लौटाती है, हर एक के साथ वह `reason` जो [समर्थित फ़ाइलें](https://docs.didit.me/hi/core-technology/electronic-signature/overview.md#समर्थित-फ़ाइलें) में दिया गया है।
- कोई फ़ील्ड अमान्य है, उसका एंकर नहीं मिलता (`field_anchor_not_found`), या कोई [फ़ील्ड मान](#फ़ील्ड-मान) अस्वीकार होता है।उसी `workflow_id` और `vendor_data` के साथ सत्र बनाने के लिए फिर से कॉल करने पर लंबित सत्र लौटता है। यदि वह कॉल `sign` भेजती है, तो उसके दस्तावेज़, फ़ील्ड और फ़ील्ड मान पहली कॉल जैसे ही होने चाहिए (वही क्रम, शीर्षक, फ़ाइल नाम, सामग्री, फ़ील्ड और मान)। किसी भी अंतर पर `{"sign": "signature_document_changed"}` के साथ `400` लौटता है: या तो अलग `vendor_data` उपयोग करें, या लंबित सत्र पूरा होने तक प्रतीक्षा करें।## सैंडबॉक्स परिदृश्यों से परीक्षणसैंडबॉक्स मोड वाले एप्लिकेशन पर, `sandbox_scenario` पास करें ताकि असली प्रदाताओं या आपके बैलेंस को छुए बिना एक निश्चित परिणाम (स्वीकृति, कोई विशिष्ट अस्वीकृति, या समीक्षाधीन परिदृश्य) पहले से लोड हो जाए:```json theme={null}
{
"workflow_id": "YOUR_SANDBOX_WORKFLOW_ID",
"sandbox_scenario": "decline_document_expired"
}
```लाइव एप्लिकेशन पर `sandbox_scenario` को `400` के साथ अस्वीकार किया जाता है। यदि सत्र बनाते समय आपको परिणाम पता नहीं है, तो उसे बाद में `POST /v3/session/{session_id}/sandbox/arm/` से सेट (या दोबारा सेट) करें, बशर्ते सत्र अभी भी `Not Started` हो: होस्टेड फ़्लो का प्री-फ़्लो परिदृश्य चुनने वाला टूल भी इसी एंडपॉइंट का उपयोग करता है। पूरी परिदृश्य सूची, मैजिक-वैल्यू रजिस्ट्री और आर्म करने वाला endpoint का रिक्वेस्ट/रिस्पॉन्स ढाँचा जानने के लिए [सैंडबॉक्स और परीक्षण डेटा](https://docs.didit.me/hi/integration/sandbox-testing.md) देखें।## `vendor_data` सत्र को एक इकाई से जोड़ता है- KYC वर्कफ़्लो के लिए: यह एक [उपयोगकर्ता इकाई](https://docs.didit.me/hi/entities/users/overview.md) से जुड़ता है। यदि उपयोगकर्ता मौजूद नहीं है, तो वह अपने-आप बन जाता है।
- KYB वर्कफ़्लो के लिए: यह एक [व्यवसाय इकाई](https://docs.didit.me/hi/entities/businesses/overview.md) से जुड़ता है। नई होने पर अपने-आप बन जाती है।अधिक जानने के लिए [vendor\_data लिंकिंग](https://docs.didit.me/hi/entities/vendor-data-linking.md) देखें।## इलिनॉय, टेक्सास और कोलोराडो में बायोमेट्रिक सहमतिहोस्टेड फ़्लो और नेटिव SDK 4.10.0 या उसके बाद के संस्करण में, एप्लिकेशन के सहमति मोड और व्यक्ति के स्थान के आधार पर, पहली बार चेहरा कैप्चर करने से पहले एक स्पष्ट बायोमेट्रिक सहमति चरण दिखाया जा सकता है। इस निर्णय में दो वैकल्पिक फ़ील्ड मदद करते हैं:- `user_state`: व्यक्ति कहाँ रहता है, जब आपको पता हो कि व्यक्ति कहाँ रहता है (`US-IL`, `IL` या `Illinois`)। Auto मोड में, कवरेज वाले राज्य में होने पर फ़्लो सहमति माँगता है।
- `biometric_consent`: `given_at` और `text_version` वाला एक ऑब्जेक्ट, उस सहमति के लिए जो आपने पहले ही ले ली है। फ़्लो दोबारा नहीं पूछता।4.10.0 से पहले के नेटिव SDK यह चरण नहीं दिखा सकते: उनके सत्र पहले की तरह चलते हैं और निर्णय में सहमति को एकत्र न की गई के रूप में दर्शाया जाता है। देखें [बायोमेट्रिक सहमति](https://docs.didit.me/hi/getting-started/biometric-consent.md)।## महत्वपूर्ण: प्रकटीकरण और सहमति अब भी आपके प्रोडक्ट में होते हैं`Create Session` एक सत्यापन URL और सत्र टोकन बनाता है। यह अपने आप यह सिद्ध **नहीं** करता कि आपने उपयोगकर्ता को प्रकटीकरण दिखाए हैं या आपके विशिष्ट उपयोग के मामले के लिए आवश्यक सहमति ली है।यदि आप अपने एप्लिकेशन, वेबसाइट, SDK रैपर या व्हाइट लेबल फ़्लो से Didit सत्र शुरू करते हैं, तो उपयोगकर्ता द्वारा कैप्चर शुरू करने से पहले आपको कानूनी पहलू अपने ही UX में संभालना चाहिए।## सत्यापन से पहले की अनुशंसित चेकलिस्ट1. उपयोगकर्ता को बताएँ कि यह सत्यापन **आपकी कंपनी** द्वारा माँगा जा रहा है और इस फ़्लो को **Didit** सत्यापन प्रदाता / प्रोसेसर के रूप में चला रहा है।
2. **आपकी गोपनीयता सूचना** और इस प्रक्रिया पर लागू होने वाली किसी भी नियंत्रक-पक्ष कानूनी शर्त से लिंक करें।
3. Didit की [पहचान सत्यापन गोपनीयता सूचना](https://didit.me/terms/verification-privacy-notice) और [पहचान सत्यापन के लिए अंतिम उपयोगकर्ता की शर्तों](https://didit.me/terms/identity-verification) से लिंक करें।
4. यदि आपके वर्कफ़्लो में दस्तावेज़ कैप्चर, सेल्फ़ी कैप्चर, लाइवनेस या बायोमेट्रिक्स शामिल हैं, तो जहाँ लागू कानून या आपकी कानूनी स्थिति इसकी माँग करती है, वहाँ **स्पष्ट सकारात्मक सहमति** लें।
5. यदि आप कस्टम UI, कस्टम डोमेन या केवल-API प्रक्रिया का उपयोग करते हैं, तो उपयोगकर्ता को Didit फ़्लो में भेजने से पहले ये प्रकटीकरण अपने प्रोडक्ट में प्रदर्शित करें।
6. यदि आपकी कानूनी टीम ऑडिट ट्रेल चाहती है, तो सूचना / सहमति के पाठ, समय-मुहर और संबंधित मेटाडेटा का अपना रिकॉर्ड रखें।> [!WARNING]
>
> कानूनी आवश्यकताएँ क्षेत्राधिकार के अनुसार अलग-अलग होती हैं। व्हाइट लेबल ब्रांडिंग सत्यापन फ़्लो में Didit की भूमिका को समाप्त नहीं करती। यदि आप बायोमेट्रिक-विशिष्ट नियमों वाले क्षेत्राधिकारों में संचालन करते हैं, तो लॉन्च से पहले अपने कार्यान्वयन की समीक्षा कानूनी सलाहकार से करवाएँ।
## OpenAPI
````yaml hi/openapi-25.json POST /v3/session/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: पहचान सत्यापन API। x-api-key हेडर के साथ प्रमाणीकृत करें।
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/session/:
post:
tags:
- Sessions
summary: एक सत्यापन सत्र बनाएँ
description: >-
एक उपयोगकर्ता सत्यापन (KYC) या व्यवसाय सत्यापन (KYB) सत्र बनाएं और अपने
अंतिम उपयोगकर्ता के लिए रीडायरेक्ट या एम्बेड करने हेतु एक होस्टेड
सत्यापन `url` के साथ `session_token` प्राप्त करें। `workflow_id` यह
चुनता है कि कौन से सत्यापन चरण चलेंगे और सत्र KYC है या KYB।
जब भी किसी उपयोगकर्ता या व्यवसाय को सत्यापित करने की आवश्यकता हो, इसे
अपने बैकएंड से कॉल करें (ब्राउज़र से कभी नहीं — API कुंजी एक सीक्रेट
है): साइनअप पर, किसी संवेदनशील कार्रवाई से पहले, या जब पुनः सत्यापन की
आवश्यकता हो। पूर्वापेक्षाएँ: एक प्रकाशित वर्कफ़्लो (कंसोल के
[Workflows](https://docs.didit.me/hi/console/workflows) पेज में बनाया
गया) और उपलब्ध क्रेडिट वाली एक एप्लिकेशन API कुंजी। सैंडबॉक्स एप्लिकेशन
क्रेडिट जाँच को बायपास कर देते हैं।
**आइडेम्पोटेंसी:** जब `vendor_data` प्रदान किया जाता है और उसी
`vendor_data` वाला एक अधूरा सत्र (`Not Started`, `In Progress`,
`Resubmitted`, या `Awaiting User`) वर्कफ़्लो के **वर्तमान नवीनतम
प्रकाशित संस्करण** पर पहले से मौजूद होता है (और उस सत्र के पास पहले से
ही एक होस्टेड सत्यापन URL होता है), तो डुप्लिकेट बनाने के बजाय मौजूदा
सत्र लौटाया जाता है (फिर भी `201`) — जिसमें इसके `callback` और
`metadata` को नए प्रदान किए गए मानों के साथ अपडेट कर दिया जाता है।
वर्कफ़्लो के पुराने संस्करण पर बनाया गया अधूरा सत्र (जिसे बाद में फिर से
प्रकाशित किया गया है) दोबारा उपयोग **नहीं** किया जाता है; इसके बजाय
नवीनतम प्रकाशित संस्करण से जुड़ा एक नया सत्र बनाया जाता है। `Approved`,
`Declined`, `In Review`, `Expired`, `Abandoned`, या `Kyc Expired` वाले
सत्रों का कभी भी दोबारा उपयोग नहीं किया जाता है।
**साइड इफ़ेक्ट:** होस्टेड सत्यापन URL जेनरेट और संग्रहीत किया जाता है;
यदि `contact_details.send_notification_emails` `true` है और एक ईमेल
प्रदान किया गया है, तो एक सत्यापन आमंत्रण ईमेल भेजा जाता है। वर्कफ़्लो
के कॉन्फ़िगर किए गए सत्र समाप्ति समय के बाद सत्र समाप्त हो जाता है। KYB
वर्कफ़्लो के लिए, `contact_details.phone` और `expected_details` को
अनदेखा कर दिया जाता है।
operationId: post_v3_session_create
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- workflow_id
properties:
workflow_id:
type: string
format: uuid
description: >-
वर्कफ़्लो का स्थिर पहचानकर्ता जो परिभाषित करता है कि सत्र
कौन से सत्यापन चरणों को चलाएगा। वर्कफ़्लो कंसोल के
[Workflows](/hi/console/workflows) पृष्ठ में बनाए और
प्रबंधित किए जाते हैं। `workflow_id` अप्रत्यक्ष रूप से यह भी
चुनता है कि सत्र KYC है या KYB।
example: 11111111-2222-3333-4444-555555555555
x-readme-id: '0.0'
vendor_data:
type: string
description: >-
सत्यापित किए जा रहे उपयोगकर्ता के लिए एक विशिष्ट पहचानकर्ता,
जैसे UUID, ईमेल या आंतरिक उपयोगकर्ता ID। इस फ़ील्ड का उपयोग
इसके लिए किया जाता है: (1) **उपयोगकर्ता समूहीकरण** — समान
vendor_data वाले सत्र Users टैब में समान उपयोगकर्ता
प्रोफ़ाइल से लिंक होते हैं। (2) **क्रॉस-सत्र डुप्लिकेट
डिटेक्शन** — डुप्लिकेट चेहरों, दस्तावेज़ों, फ़ोन नंबरों,
ईमेल, IP पतों या डिवाइस फ़िंगरप्रिंट की जाँच करते समय, समान
vendor_data वाले सत्रों को एक ही उपयोगकर्ता माना जाता है और
मिलानों से बाहर रखा जाता है। vendor_data के बिना, प्रत्येक
सत्र को एक अद्वितीय उपयोगकर्ता माना जाता है और सभी संभावित
डुप्लिकेट सामने लाए जाते हैं। हम डुप्लिकेट डिटेक्शन में
अनावश्यक डेटा कम करने के लिए हमेशा vendor_data प्रदान करने
की पुरज़ोर अनुशंसा करते हैं।
example: user-123
x-readme-id: '0.1'
multi_account_segment:
type: string
maxLength: 64
description: >-
आपके संगठन के भीतर वैकल्पिक डुप्लिकेट-डिटेक्शन क्षेत्र।
डुप्लिकेट चेहरा जांच इस सत्र की तुलना केवल उसी सेगमेंट वाले
अन्य सत्रों से करती है, ताकि अलग-अलग खाता आधार (व्यक्तिगत और
व्यावसायिक खाते, या प्रति B2B सब-क्लाइंट एक) ऐसे व्यक्ति को
फ़्लैग न करें जिसके पास वैध रूप से दोनों में एक-एक खाता है।
एकल डिफ़ॉल्ट क्षेत्र का उपयोग करने के लिए इसे छोड़ दें,
जिसका उपयोग आज प्रत्येक सत्र करता है। ब्लॉकलिस्ट और अनुमति
सूची मिलान इस फ़ील्ड को अनदेखा करते हैं।
example: business-accounts
callback:
type: string
description: >-
सत्यापन पूरा होने के बाद उपयोगकर्ता को रीडायरेक्ट करने का
URL। Didit स्वचालित रूप से क्वेरी पैरामीटर के रूप में
`verificationSessionId` और `status` (Approved, Declined, In
Review) जोड़ता है। मोबाइल कॉलबैक के लिए कस्टम URL स्कीम्स
(जैसे `myapp://`) समर्थित हैं। यदि छोड़ दिया जाता है, तो
वर्कफ़्लो के डिफ़ॉल्ट `callback_url` का उपयोग किया जाता है।
जब एप्लिकेशन में अनुमत डोमेन (`PATCH /v3/webhook/` पर
`allowed_domains`) होते हैं, तो एक `http` या `https` कॉलबैक
उन ऑरिजिनों में से एक पर होना चाहिए (समान स्कीम, होस्ट और
पोर्ट), अन्यथा `callback` पर 400 के साथ अनुरोध विफल हो जाता
है: `callback must be on one of the application's allowed
domains: https://app.example.com`। कस्टम URL स्कीम्स हमेशा
स्वीकार किए जाते हैं।
example: https://example.com/verification/callback
x-readme-id: '0.2'
callback_method:
type: string
description: >-
निर्धारित करता है कि प्रदान किए गए कॉलबैक URL पर रीडायरेक्ट
को किस डिवाइस को संभालना चाहिए। केवल उस डिवाइस को रीडायरेक्ट
करने के लिए `initiator` का उपयोग करें जिसने प्रवाह शुरू किया
था, इसे पूरा करने वाले डिवाइस के लिए `completer`, या किसी भी
डिवाइस को कॉलबैक ट्रिगर करने की अनुमति देने के लिए `both` का
उपयोग करें। यदि आप कभी देखते हैं कि कॉलबैक विश्वसनीय रूप से
ट्रिगर नहीं हो रहा है, तो हम इस मान को `both` पर सेट करने की
अनुशंसा करते हैं।
enum:
- initiator
- completer
- both
default: initiator
example: both
x-readme-id: '0.3'
metadata:
description: >-
सत्र के साथ संग्रहीत मनमाना JSON जो रिस्पॉन्स और webhooks
में वापस लौटाया जाता है। कोई भी JSON मान स्वीकार किया जाता
है (ऑब्जेक्ट, स्ट्रिंग, संख्या, ऐरे), लेकिन key/value
युग्मों के एक JSON ऑब्जेक्ट की अनुशंसा की जाती है। अंतिम
उपयोगकर्ता को नहीं दिखाया जाता। अपनी स्वयं की कोरिलेशन IDs,
A/B वेरिएंट, या व्यावसायिक संदर्भ पास करने के लिए इसका उपयोग
करें।
example:
user_type: premium
account_id: ABC123
x-readme-id: '0.4'
tags:
type: array
items:
type: string
maxLength: 50
maxItems: 10
description: >-
सत्र बनाते समय नाम के आधार पर उसमें जोड़े गए टैग। अधिकतम 10,
प्रत्येक 50 वर्णों तक। नाम केस-असंवेदनशील होते हैं और बड़े
अक्षरों में संग्रहीत किए जाते हैं। जो नाम एप्लिकेशन में अभी
तक मौजूद नहीं है, उसे एक नए टैग के रूप में बनाया जाता है। ये
टैग कंसोल में सत्र पर दिखाई देते हैं, जहाँ आप उनके अनुसार
फ़िल्टर कर सकते हैं।
example:
- VIP
- ONBOARDING Q4
language:
type: string
description: >-
सत्यापन प्रक्रिया इंटरफ़ेस के लिए भाषा कोड (ISO 639-1)।
सत्यापन के दौरान अंतिम उपयोगकर्ता को दिखाई जाने वाली भाषा को
नियंत्रित करता है। यदि प्रदान नहीं किया जाता है, तो ब्राउज़र
की भाषा स्वचालित रूप से पहचानी जाएगी और उपयोग की जाएगी। सभी
समर्थित भाषाएँ [यहाँ](/hi/integration/supported-languages)
देखें।
enum:
- en
- ar
- bg
- bn
- bs
- ca
- cnr
- cs
- da
- de
- el
- es
- et
- fa
- fi
- fr
- he
- hi
- hr
- hu
- hy
- id
- it
- ja
- ka
- kk
- ko
- ky
- lt
- lv
- mk
- mn
- ms
- nl
- 'no'
- pl
- pt-BR
- pt
- ro
- ru
- sk
- sl
- so
- sq
- sr
- sv
- th
- tr
- uk
- uz
- vi
- zh-CN
- zh-TW
- zh
example: en
x-readme-id: '0.5'
contact_details:
type: object
description: >-
उपयोगकर्ता संपर्क जानकारी जिसका उपयोग सूचनाओं, सत्यापन
फ़ॉर्म को पहले से भरने और फ़ोन सत्यापन के लिए किया जा सकता
है। इसमें ईमेल पता, संचार के लिए पसंदीदा भाषा और फ़ोन नंबर
शामिल हैं।
example:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
properties:
email:
type: string
format: email
description: >-
उपयोगकर्ता का ईमेल पता (उदा. "john.doe@example.com")
जिसका उपयोग [ईमेल
सत्यापन](/hi/core-technology/email-verification/overview)
चरण के दौरान किया जाएगा। यदि प्रदान नहीं किया गया है, तो
उपयोगकर्ता को इसे सत्यापन प्रवाह के दौरान प्रदान करना
होगा।
example: john.doe@example.com
x-readme-id: '1.0'
send_notification_emails:
type: boolean
default: false
description: >-
यदि true है और कोई ईमेल प्रदान किया गया है, तो Didit
उपयोगकर्ता सत्यापन (KYC) या व्यवसाय सत्यापन (KYB) सत्र
बनने पर प्रारंभिक "Verify your identity" ईमेल एसिंक्रोनस
रूप से भेजता है। Didit प्रदान किए गए ईमेल पते पर
मैन्युअल समीक्षा की आवश्यकता वाले सत्रों के लिए सत्यापन
स्थिति सूचनाएं भी भेजता है (उदा. 'In Review' से
'Approved' या 'Declined')। इससे उपयोगकर्ताओं को उनका
सत्यापन पूरा होने के बाद आपके एप्लिकेशन पर लौटने में मदद
मिलती है। यदि आपने सत्र के लिए व्हाइट लेबल सक्रिय किया
है, तो भेजा गया ईमेल व्हाइट लेबल होगा।
example: true
x-readme-id: '1.1'
email_lang:
type: string
description: >-
ईमेल सूचनाओं के लिए भाषा कोड (ISO 639-1)। सभी ईमेल
संचारों की भाषा को नियंत्रित करता है (उदा. "en", "es",
"fr")। कोई संग्रहीत डिफ़ॉल्ट नहीं है — छोड़े जाने पर,
सत्यापन आमंत्रण ईमेल भेजते समय सीधे अंग्रेज़ी (`en`) पर
फ़ालबैक करता है। नीचे दिया गया enum एक स्नैपशॉट है;
स्वीकृत मानों के लिए लाइव सोर्स ऑफ़ ट्रुथ [समर्थित
भाषाएँ](/hi/integration/supported-languages) दस्तावेज़
है — किसी विशिष्ट कोड पर निर्भर रहने से पहले हमेशा इसे
देखें।
enum:
- en
- ar
- bg
- bn
- bs
- ca
- cnr
- cs
- da
- de
- el
- es
- et
- fa
- fi
- fr
- he
- hi
- hr
- hu
- hy
- id
- it
- ja
- ka
- kk
- ko
- ky
- lt
- lv
- mk
- mn
- ms
- nl
- 'no'
- pl
- pt-BR
- pt
- ro
- ru
- sk
- sl
- so
- sq
- sr
- sv
- th
- tr
- uk
- uz
- vi
- zh-CN
- zh-TW
- zh
example: en
x-readme-id: '1.2'
phone:
type: string
description: >-
E.164 प्रारूप में फ़ोन नंबर (उदा., "+14155552671") जिसका
उपयोग [फ़ोन
सत्यापन](/hi/core-technology/phone-verification/overview)
चरण के दौरान किया जाएगा। यदि प्रदान नहीं किया गया है, तो
उपयोगकर्ता को इसे सत्यापन प्रवाह के दौरान प्रदान करना
होगा। व्यवसाय सत्यापन (KYB) वर्कफ़्लो के लिए अनदेखा किया
जाता है। **महत्वपूर्ण:** यह फ़ोन नंबर केवल तभी लागू किया
जाता है जब यह एक मान्य E.164 फ़ोन नंबर हो। यदि प्रदान
किया गया नंबर अमान्य है या इसे पार्स नहीं किया जा सकता
है, तो इसे अनदेखा कर दिया जाएगा और उपयोगकर्ता फ़ोन
सत्यापन चरण के दौरान कोई भी मान्य फ़ोन नंबर दर्ज कर
सकेगा।
example: '+14155552671'
x-readme-id: '1.3'
x-readme-id: '0.4'
expected_details:
type: object
description: >-
उपयोगकर्ता के पहचान दस्तावेज़, पते का प्रमाण, और अन्य
सत्यापन चरणों से निकाले गए डेटा के विरुद्ध क्रॉस-सत्यापन के
लिए उपयोग किए जाने वाले अपेक्षित उपयोगकर्ता विवरण। बेमेल
होने पर निर्णय में चेतावनियों के रूप में दिखाया जाता है; कुछ
फ़ील्ड (जैसे `id_country`, `expected_document_types`)
उपयोगकर्ता-सामना करने वाले प्रवाह को भी बदलते हैं। व्यवसाय
सत्यापन (KYB) वर्कफ़्लो के लिए केवल व्यवसाय फ़ील्ड
(`company_name`, `registry_country`, `registration_number`)
का उपयोग किया जाता है — वे उपयोगकर्ता के लिए कंपनी रजिस्ट्री
खोज को पहले से भरते हैं — और सभी व्यक्ति-स्तरीय फ़ील्ड को
अनदेखा कर दिया जाता है।
example:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
nationality: USA
id_country: USA
expected_document_types:
- P
- ID
properties:
first_name:
type: string
description: >-
उपयोगकर्ता का पहला नाम। उदाहरण के लिए, `John`। मिलान
फ़ज़ी तुलना का उपयोग करता है, और आप ID Document और पते
का प्रमाण दोनों वर्कफ़्लो के लिए कंसोल में नाम मिलान
स्कोर थ्रेशोल्ड कॉन्फ़िगर करके कड़ाई को ट्यून कर सकते
हैं।
example: John
x-readme-id: '1.0'
last_name:
type: string
description: >-
उपयोगकर्ता का अंतिम नाम। उदाहरण के लिए, `Doe`। मिलान
फ़ज़ी तुलना का उपयोग करता है, और आप ID Document और पते
का प्रमाण दोनों वर्कफ़्लो के लिए कंसोल में नाम मिलान
स्कोर थ्रेशोल्ड कॉन्फ़िगर करके कड़ाई को ट्यून कर सकते
हैं।
example: Doe
x-readme-id: '1.1'
date_of_birth:
type: string
format: date
description: >-
उपयोगकर्ता की जन्म तिथि, प्रारूप: YYYY-MM-DD। उदाहरण के
लिए, `1990-05-15`।
example: '1990-05-15'
x-readme-id: '1.2'
gender:
type: string
nullable: true
enum:
- M
- F
default: null
description: उपयोगकर्ता का लिंग। 'M', 'F', या null होना चाहिए।
example: M
x-readme-id: '1.3'
nationality:
type: string
description: >-
आवेदक के मूल देश का प्रतिनिधित्व करने वाला ISO 3166-1
alpha-3 देश कोड। उदाहरण के लिए, `USA`। [समर्थित देश
कोडों की पूरी
सूची](https://docs.didit.me/hi/core-technology/id-verification/supported-documents-id-verification#देश-के-अनुसार-समर्थित-दस्तावेज़)
देखें।
example: USA
x-readme-id: '1.4'
country:
type: string
description: >-
पहचान सत्यापन और पते का प्रमाण दोनों की देश-बेमेल जांचों
के लिए फ़ॉलबैक के रूप में उपयोग किया जाने वाला ISO
3166-1 alpha-3 देश कोड। जब `address` प्रदान किया गया हो
और न तो `id_country` और न ही `poa_country` सेट हो, तब
आवश्यक है।
example: USA
x-readme-id: 1.4.1
id_country:
type: string
description: >-
आवेदक के ID दस्तावेज़ के अपेक्षित देश का प्रतिनिधित्व
करने वाला ISO 3166-1 alpha-3 देश कोड, जो राष्ट्रीयता से
भिन्न हो सकता है। उदाहरण के लिए, `GBR`। पहचान सत्यापन
देश बेमेल जांचों के लिए `country` की तुलना में इसे
प्राथमिकता दी जाती है। [समर्थित देश कोडों की पूरी
सूची](https://docs.didit.me/hi/core-technology/id-verification/supported-documents-id-verification#देश-के-अनुसार-समर्थित-दस्तावेज़)
देखें।
example: GBR
x-readme-id: '1.5'
poa_country:
type: string
description: >-
पते का प्रमाण दस्तावेज़ के अपेक्षित देश का प्रतिनिधित्व
करने वाला ISO 3166-1 alpha-3 देश कोड। उदाहरण के लिए,
`USA`। POA देश बेमेल जांचों के लिए `country` की तुलना
में इसे प्राथमिकता दी जाती है। [समर्थित देश कोडों की
पूरी
सूची](https://docs.didit.me/hi/core-technology/id-verification/supported-documents-id-verification#देश-के-अनुसार-समर्थित-दस्तावेज़)
देखें।
example: USA
x-readme-id: 1.5.1
address:
type: string
description: >-
मानव पठनीय प्रारूप में पता, जिसमें यथासंभव अधिक जानकारी
शामिल हो। उदाहरण के लिए, `123 Main St, San Francisco, CA
94105, USA`। प्रदान किए जाने पर, आपको `country` या
`poa_country` भी पास करना होगा, अन्यथा अनुरोध `400` के
साथ विफल हो जाता है।
example: 123 Main St, San Francisco, CA 94105, USA
x-readme-id: '1.6'
identification_number:
type: string
description: >-
उपयोगकर्ता का दस्तावेज़ नंबर, व्यक्तिगत नंबर, या कर
नंबर। उदाहरण के लिए, `123456789`।
example: '123456789'
x-readme-id: '1.7'
ip_address:
type: string
description: >-
सत्र के लिए अपेक्षित IP पता, IPv4 या IPv6 प्रारूप में।
यदि वास्तविक IP पता इस मान से भिन्न है, तो एक चेतावनी
लॉग की जाएगी। उदाहरण के लिए, `192.168.1.100` या
`2001:db8::1`।
example: 192.168.1.100
x-readme-id: '1.8'
expected_document_types:
type: array
description: >-
पहचान सत्यापन (OCR) चरण के दौरान उपयोगकर्ता द्वारा
प्रस्तुत किए जा सकने वाले दस्तावेज़ प्रकारों को सीमित
करता है। सेट होने पर, दस्तावेज़ चयन स्क्रीन केवल
अनुरोधित प्रकारों को दिखाती है और लौटाया गया
`documents_allowed` उसी के अनुसार फ़िल्टर किया जाता है।
मान केस-इनसेंसिटिव होते हैं और डुप्लिकेट हटा दिए जाते
हैं; अज्ञात मानों को `400` के साथ अस्वीकार कर दिया जाता
है। अनुमत कोड: `P` (पासपोर्ट), `ID` (राष्ट्रीय पहचान
पत्र), `DL` (ड्राइविंग लाइसेंस), `RP` (निवास परमिट),
`HIC` (स्वास्थ्य बीमा कार्ड), `TC` (टैक्स कार्ड), `SSC`
(सोशल सिक्योरिटी कार्ड)।
items:
type: string
enum:
- P
- ID
- DL
- RP
- HIC
- TC
- SSC
example:
- P
- ID
x-readme-id: '1.9'
company_name:
type: string
maxLength: 255
description: >-
सत्यापित किए जा रहे व्यवसाय का अपेक्षित कानूनी नाम।
उदाहरण के लिए, `Tesco PLC`। व्यवसाय सत्यापन (KYB)
वर्कफ़्लो में रजिस्ट्री खोज के कंपनी-नाम फ़ील्ड को पहले
से भरता है; जब `registration_number` भी प्रदान किया जाता
है, तो रजिस्ट्री लुकअप दोनों पहचानकर्ताओं को जोड़ता है।
KYC वर्कफ़्लो के लिए अनदेखा किया जाता है।
example: Tesco PLC
x-readme-id: '1.10'
registry_country:
type: string
maxLength: 10
description: >-
उस देश का ISO 3166-1 alpha-2 कोड जिसकी कंपनी रजिस्ट्री
में व्यवसाय पंजीकृत है। उदाहरण के लिए, `GB`। जहाँ कंपनी
रजिस्ट्रियाँ राज्य या प्रांत स्तर पर संचालित होती हैं,
वहाँ ISO 3166-2 सबडिवीजन कोड को `XX-YY` के रूप में
जोड़ें: `US-CA` कैलिफ़ोर्निया रजिस्ट्री को लक्षित करता
है। [KYB Registry Search
API](https://docs.didit.me/hi/standalone-apis/kyb-registry-search)
पर `country_code` के समान प्रारूप। व्यवसाय सत्यापन (KYB)
वर्कफ़्लो में रजिस्ट्री देश का पूर्व-चयन करता है; KYC
वर्कफ़्लो के लिए इसे अनदेखा किया जाता है।
example: US-CA
x-readme-id: '1.11'
registration_number:
type: string
maxLength: 100
description: >-
कंपनी रजिस्ट्री में व्यवसाय की अपेक्षित पंजीकरण संख्या।
उदाहरण के लिए, `00445790`। व्यवसाय सत्यापन (KYB)
वर्कफ़्लो में रजिस्ट्री खोज के पंजीकरण-संख्या फ़ील्ड को
पहले से भरता है; जब `company_name` भी प्रदान किया जाता
है, तो रजिस्ट्री लुकअप दोनों पहचानकर्ताओं को जोड़ता है।
KYC वर्कफ़्लो के लिए अनदेखा किया जाता है।
example: '00445790'
x-readme-id: '1.12'
x-readme-id: '0.5'
portrait_image:
type: string
format: byte
description: >-
अंतिम उपयोगकर्ता के चेहरे की Base64-एन्कोडेड पोर्ट्रेट छवि
(अधिकतम 2MB; JPEG, PNG, WebP, या TIFF)। जब वर्कफ़्लो चेहरा
मिलान सक्षम वाला `Biometric Authentication` वर्कफ़्लो हो, या
कोई ऐसा ग्राफ़ वर्कफ़्लो हो जहाँ पहचान सत्यापन (OCR) से पहले
चेहरा मिलान चलता है, तो लाइवनेस कैप्चर के विरुद्ध मिलान करने
के लिए संदर्भ छवि के रूप में उपयोग किया जाता है। जब
`vendor_data` उपयोगकर्ता के पास पहले से संग्रहीत चेहरे की
छवि होती है, तो यह वैकल्पिक है: Didit इसे स्वचालित रूप से
पुनः उपयोग करता है, जिसे प्राथमिकता क्रम में हल किया जाता
है: स्वीकृत लाइवनेस चेहरा, ePassport चिप फ़ोटो, पहचान
दस्तावेज़ पोर्ट्रेट, मैन्युअल रूप से नामांकित प्रोफ़ाइल
चेहरा (केवल स्वीकृत सत्रों के चेहरे या आपके द्वारा स्वयं
नामांकित चेहरे ही पुनः उपयोग किए जाते हैं)। प्रदान किए जाने
पर, `portrait_image` हमेशा संग्रहीत चेहरे पर वरीयता लेता है।
यदि छोड़ दिया जाता है और कोई संग्रहीत चेहरा मौजूद नहीं है
(या `vendor_data` नहीं भेजा गया है), तो सत्र निर्माण `400`
के साथ विफल हो जाता है। अन्य वर्कफ़्लो प्रकारों के लिए
अनदेखा किया जाता है।
example: >-
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=
x-readme-id: '0.6'
sandbox_scenario:
type: string
description: >-
केवल-सैंडबॉक्स परिदृश्य स्लग। केवल तभी स्वीकार किया जाता है
जब API कुंजी किसी सैंडबॉक्स-मोड एप्लिकेशन से संबंधित हो;
लाइव एप्लिकेशन पर अस्वीकार कर दिया जाता है। सेट होने पर,
निर्माण फ़्लो परिदृश्य के बंडल किए गए मैजिक मानों को सत्र के
इनपुट फ़ील्ड्स (contact_details, expected_details) पर
विस्तारित करता है ताकि मॉक किए गए प्रदाता वास्तविक वर्कफ़्लो
पाइपलाइन के माध्यम से परिदृश्य के परिणाम को पुनरुत्पादित
करें। परिदृश्य कैटलॉग को GET /v1/sandbox/scenarios/ पर या
[Sandbox & Test Data](/hi/integration/sandbox-testing)
देखें। आप निर्माण के बाद POST
/v3/session/{sessionId}/sandbox/arm/ के माध्यम से किसी
परिदृश्य को आर्म (या पुनः आर्म) भी कर सकते हैं, जब तक कि
सत्र अभी भी `Not Started` स्थिति में हो। गैर-दस्तावेज़ लुकअप
के लिए, कॉन्फ़िगर किए गए प्रयास बजट और फ़ॉलबैक का परीक्षण
करने हेतु `lookup_partial_match`, `lookup_no_match`, या
`lookup_provider_error` का उपयोग करें। पहचान वॉलेट के लिए,
`wallet_cancelled`, `wallet_timeout`, या
`wallet_provider_error` का उपयोग करें; `approve` एक सत्यापित
वॉलेट का अनुकरण करता है। सभी कैटलॉग वॉलेट का सैंडबॉक्स में
परीक्षण किया जा सकता है, जिसमें वे स्कीमें भी शामिल हैं जो
लाइव एप्लिकेशन पर उपलब्ध नहीं हैं। अनुकरण किए गए प्रयासों के
लिए कोई शुल्क नहीं लिया जाता है।
example: decline_document_expired
sign:
type: object
description: >-
इस सत्र के लिए ई-हस्ताक्षर इनपुट। `documents` हस्ताक्षर किए
जाने वाले दस्तावेज़ हैं, ऐसे वर्कफ़्लो के लिए जिसका
ई-हस्ताक्षर चरण सत्र से दस्तावेज़ लेता है
(`signature_documents_source` `session` या `both`): कुल
मिलाकर अधिकतम 20 दस्तावेज़ और 50 MB। `field_values` उन
फ़ील्ड को भरता है जिनका `prefill` वर्कफ़्लो और सत्र, दोनों
के दस्तावेज़ों में `api.` है। समान `workflow_id` और
`vendor_data` के लिए फिर से सत्र बनाने पर लंबित सत्र वापस
मिलता है; यदि वह कॉल `sign` भेजती है, तो उसके दस्तावेज़,
फ़ील्ड और मान पहले वाले के समान होने चाहिए, और कुछ भी भिन्न
होने पर `{"sign": "signature_document_changed"}` के साथ
`400` वापस मिलता है। [ई-हस्ताक्षर
दस्तावेज़](/hi/sessions-api/create-session#ई-हस्ताक्षर-दस्तावेज़)
देखें।
properties:
documents:
type: array
minItems: 1
maxItems: 20
items:
$ref: '#/components/schemas/SessionSignDocument'
field_values:
type: object
description: >-
प्रत्येक `api.` प्री-फ़िल स्रोत के `` द्वारा
कीड मान: `text` और `data` फ़ील्ड के लिए 1 से 500 वर्णों
की स्ट्रिंग, `checkbox` के लिए बूलियन। किसी ऐसी की (key)
के लिए `field_value_unknown` के साथ `400` जिसका उपयोग
कोई फ़ील्ड नहीं करता है, अपने मान के बिना आवश्यक फ़ील्ड
के लिए `field_value_missing`, और अपने फ़ील्ड के सत्यापन
में विफल रहने वाले मान के लिए `field_value_invalid`।
additionalProperties:
oneOf:
- type: string
minLength: 1
maxLength: 500
- type: boolean
example:
credit_limit: 3,000 EUR
user_state:
type: string
maxLength: 16
description: >-
व्यक्ति कहाँ रहता है, जब आपको यह पता हो: एक ISO 3166-2
सबडिवीजन कोड (`US-IL`, `ES-M`) या एक US राज्य कोड या नाम
(`IL`, `Illinois`)। ऐसा राज्य जिसका कानून स्पष्ट बायोमेट्रिक
सहमति की मांग करता है (Illinois, Texas, Colorado), सत्यापन
फ़्लो में चेहरा कैप्चर करने से पहले `declared_state` ट्रिगर
के साथ इसके लिए सहमति मांगी जाती है। अपरिचित मान `400`
लौटाता है। देखें [बायोमेट्रिक
सहमति](/hi/getting-started/biometric-consent)।
example: US-IL
biometric_consent:
type: object
description: >-
स्पष्ट बायोमेट्रिक सहमति जो आपने व्यक्ति से पहले ही एकत्र कर
ली है। यह आवश्यकता को पूरा करती है, इसलिए सत्यापन प्रवाह
दोबारा नहीं पूछता है, और निर्णय इसे `customer_collected`
ट्रिगर के साथ `status: "given"` के रूप में रिकॉर्ड करता है।
व्यक्ति द्वारा प्रवाह में पहले दिया गया उत्तर कभी नहीं बदला
जाता है। देखें [बायोमेट्रिक
सहमति](/hi/getting-started/biometric-consent)।
required:
- given_at
- text_version
properties:
given_at:
type: string
format: date-time
description: >-
व्यक्ति ने स्पष्ट बायोमेट्रिक सहमति कब दी (ISO 8601)।
भविष्य की तिथि नहीं हो सकती।
text_version:
type: string
maxLength: 64
description: >-
व्यक्ति द्वारा स्वीकार किए गए सहमति टेक्स्ट का संस्करण
id, आपके अपने रिकॉर्ड में।
example:
workflow_id: 11111111-2222-3333-4444-555555555555
vendor_data: user-123
callback: https://example.com/verification/callback
callback_method: both
metadata:
user_type: premium
account_id: ABC123
language: en
contact_details:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
expected_details:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
id_country: USA
expected_document_types:
- P
- ID
examples:
Create KYC session:
summary: उपयोगकर्ता सत्यापन (KYC) सत्र के लिए पूर्ण हैप्पी-पाथ payload
description: >-
वास्तविक निर्माण कॉल जो प्रत्येक सामान्यतः सेट किए गए फ़ील्ड
का उपयोग करती है: वर्कफ़्लो चयन, वेंडर लिंकेज, कॉलबैक रूटिंग,
मेटाडेटा, लोकेल, संपर्क प्रीफ़िल, और अपेक्षित उपयोगकर्ता
विवरण। इसे सीधे ऊपर दिए गए cURL नमूने में कॉपी-पेस्ट करें।
value:
workflow_id: 11111111-2222-3333-4444-555555555555
vendor_data: user-123
callback: https://example.com/verification/callback
callback_method: both
metadata:
user_type: premium
account_id: ABC123
language: en
contact_details:
email: john.doe@example.com
send_notification_emails: true
email_lang: en
phone: '+14155552671'
expected_details:
first_name: John
last_name: Doe
date_of_birth: '1990-05-15'
nationality: USA
id_country: USA
expected_document_types:
- P
- ID
Create KYB session:
summary: व्यवसाय सत्यापन (KYB) सत्र के लिए हैप्पी-पाथ payload
description: >-
KYC कॉल के समान आकार — `workflow_id` ही सत्र को KYB बनाता है।
`vendor_data` आमतौर पर आपके सिस्टम में कंपनी को संदर्भित करता
है और `contact_details.email` उस कानूनी प्रतिनिधि को लक्षित
करता है जो फ़्लो को पूरा करेगा। `expected_details` व्यावसायिक
फ़ील्ड्स (`company_name`, `registry_country`,
`registration_number`) को स्वीकार करता है, जो कंपनी रजिस्ट्री
खोज को पूर्व-भरते हैं; KYB वर्कफ़्लो के लिए व्यक्ति-स्तरीय
फ़ील्ड्स और `contact_details.phone` को अनदेखा कर दिया जाता है।
value:
workflow_id: 33333333-4444-5555-6666-777777777777
vendor_data: company-acme-001
callback: https://example.com/kyb/callback
callback_method: both
metadata:
tier: enterprise
company_id: ACME-001
expected_details:
company_name: Tesco PLC
registry_country: GB
registration_number: '00445790'
language: en
contact_details:
email: legal-rep@acme.example.com
send_notification_emails: true
email_lang: en
responses:
'201':
description: >-
सत्र बनाया गया (या वापस लौटाया गया, यदि वर्कफ़्लो के नवीनतम प्रकाशित
संस्करण पर समान `vendor_data` वाला कोई अधूरा सत्र पहले से मौजूद है)।
रिस्पॉन्स सीरियलाइज़ किया गया सत्र है, जिसमें उपयोगकर्ता को
रीडायरेक्ट करने के लिए होस्टेड सत्यापन `url` शामिल है।
content:
application/json:
schema:
type: object
required:
- session_id
- session_number
- session_token
- url
- vendor_data
- metadata
- status
- workflow_id
- workflow_version
- callback
properties:
session_id:
type: string
format: uuid
description: >-
सत्यापन सत्र का विशिष्ट पहचानकर्ता। `GET
/v3/session/{sessionId}/decision/` को कॉल करते समय इस id
का उपयोग करें।
example: 11111111-2222-3333-4444-555555555555
session_number:
type: integer
description: >-
आपके एप्लिकेशन के अंदर सत्र को सौंपी गई अनुक्रमिक, आसानी
से पढ़ी जाने वाली संख्या। सहायता और डैशबोर्ड के लिए
उपयोगी।
example: 43762
session_token:
type: string
description: >-
12-वर्ण का URL-सुरक्षित token जो अंतिम उपयोगकर्ता को `url`
पर होस्ट किए गए सत्यापन प्रवाह तक पहुँचने के लिए अधिकृत
करता है। सत्र समाप्त होने तक मान्य। इसे एक सीक्रेट की तरह
मानें — इसे रखने वाला कोई भी व्यक्ति इस सत्र के लिए
सत्यापन प्रवाह खोल सकता है।
example: 3FaJ9wLqX2Mz
url:
type: string
format: uri
description: >-
अंतिम उपयोगकर्ता को रीडायरेक्ट करने के लिए होस्टेड सत्यापन
URL। URL में `session_token` एम्बेड होता है और, यदि
कॉन्फ़िगर किया गया है, तो यह आपके व्हाइट लेबल डोमेन का
उपयोग करता है। जब अनुरोध में `language` शामिल होता है, तो
URL में एक भाषा पथ खंड होता है —
`https://verify.didit.me/{language}/session/{session_token}`
(उदा. `/es/session/...`); बिना `language` के, यह खंड छोड़
दिया जाता है।
example: https://verify.didit.me/session/3FaJ9wLqX2Mz
vendor_data:
type: string
nullable: true
description: >-
वह पहचानकर्ता जिसे आपने सत्र को अपने सिस्टम में किसी
उपयोगकर्ता या व्यवसाय से जोड़ने के लिए अनुरोध में पास किया
था। ज्यों का त्यों वापस भेजा जाता है। प्रदान न किए जाने पर
Null।
example: user-123
metadata:
description: >-
सत्र निर्माण के समय संग्रहीत किया गया आपका मनमाना JSON
payload। जैसा भेजा गया था वैसा ही वापस दोहराया जाता है —
आपके द्वारा भेजा गया कोई भी JSON मान (ऑब्जेक्ट, स्ट्रिंग,
संख्या, ऐरे) यथावत लौटाया जाता है, हालांकि एक JSON
ऑब्जेक्ट की अनुशंसा की जाती है। अंतिम उपयोगकर्ता को नहीं
दिखाया जाता। रिस्पॉन्स में हमेशा मौजूद रहता है; निर्माण के
समय प्रदान न किए जाने पर `null` होता है।
example:
user_type: premium
account_id: ABC123
tags:
type: array
items:
type: string
description: सत्र पर मौजूद टैग, नाम के अनुसार।
example:
- VIP
- ONBOARDING Q4
status:
type: string
enum:
- Not Started
- In Progress
- Approved
- Declined
- In Review
- Expired
- Abandoned
- Kyc Expired
- Resubmitted
- Awaiting User
description: >-
सत्र की वर्तमान स्थिति। नए बनाए गए सत्र `Not Started`
लौटाते हैं। यदि वर्कफ़्लो के नवीनतम प्रकाशित संस्करण पर
उसी `vendor_data` के लिए कोई गैर-समाप्त सत्र पहले से मौजूद
था, तो लौटाई गई स्थिति उस मौजूदा सत्र को दर्शाती है।
example: Not Started
callback:
type: string
format: uri
nullable: true
description: >-
फ़्लो पूरा करने के बाद उपयोगकर्ता को भेजा जाने वाला अंतिम
रीडायरेक्ट URL। Didit इस URL में
`?verificationSessionId={session_id}&status={status}`
जोड़ता है। अनुरोध में प्रदान न किए जाने पर वर्कफ़्लो के
कॉन्फ़िगर किए गए कॉलबैक URL पर फ़ॉलबैक करता है; दोनों सेट
न होने पर `null`। जब एप्लिकेशन में अनुमत डोमेन होते हैं और
यह URL उनके बाहर का कोई वेब URL होता है (उदाहरण के लिए
सूची बदलने से पहले सेट किया गया वर्कफ़्लो डिफ़ॉल्ट), तो
होस्टेड फ़्लो उपयोगकर्ता को उस पर रीडायरेक्ट नहीं करता है।
example: https://example.com/verification/callback
workflow_id:
type: string
format: uuid
description: >-
उस वर्कफ़्लो का स्थिर पहचानकर्ता जिस पर यह सत्र चलता है।
हमेशा वर्कफ़्लो का स्थिर समूह पहचानकर्ता — भले ही आपने
अनुरोध में किसी विशिष्ट वर्कफ़्लो संस्करण UUID का संदर्भ
दिया हो (बैकवर्ड-कम्पैटिबल लुकअप), रिस्पॉन्स में स्थिर
`workflow_id` शामिल होता है। कंसोल में आपके द्वारा
कॉन्फ़िगर किए गए वर्कफ़्लो के साथ सत्र को सहसंबंधित करने
के लिए इसका उपयोग करें।
example: 11111111-2222-3333-4444-555555555555
workflow_version:
type: integer
description: >-
प्रकाशित वर्कफ़्लो संस्करण की संस्करण संख्या जिस पर
निर्माण के समय सत्र को पिन किया गया था। सत्र बनाए जाने पर
Didit `workflow_id` को वर्कफ़्लो के नवीनतम प्रकाशित
संस्करण में हल करता है, और वर्कफ़्लो को बाद में पुनः
प्रकाशित किए जाने पर भी सत्र उसी संस्करण को चलाता रहता है।
example: 3
examples:
KYC session:
summary: KYC सत्र बनाया गया
value:
session_id: 11111111-2222-3333-4444-555555555555
session_number: 43762
session_token: 3FaJ9wLqX2Mz
url: https://verify.didit.me/en/session/3FaJ9wLqX2Mz
vendor_data: user-123
metadata:
user_type: premium
account_id: ABC123
status: Not Started
workflow_id: 11111111-2222-3333-4444-555555555555
workflow_version: 3
callback: https://example.com/verification/callback
KYB session:
summary: KYB सत्र बनाया गया
value:
session_id: 22222222-3333-4444-5555-666666666666
session_number: 43763
session_token: Yk7pQ2vN8aBc
url: https://verify.didit.me/en/session/Yk7pQ2vN8aBc
vendor_data: company-acme-001
metadata:
tier: enterprise
status: Not Started
workflow_id: 33333333-4444-5555-6666-777777777777
workflow_version: 1
callback: https://example.com/kyb/callback
'400':
description: >-
खराब अनुरोध — payload सत्यापन विफल रहा (अनुपलब्ध या अज्ञात
`workflow_id`, अमान्य `language`, ब्लॉकलिस्ट किया गया `vendor_data`,
विकृत `portrait_image`, बिना `country`/`poa_country` के `address`,
अमान्य `sandbox_scenario`, `sign` दस्तावेज़, फ़ील्ड या मान जिन्हें
वर्कफ़्लो का ई-हस्ताक्षर चरण अस्वीकार करता है, जैसे
`signature_document_not_supported`,
`signature_document_conversion_failed`, `field_anchor_not_found` या
`field_value_missing`, आदि) या आपके संगठन के पास सत्र शुरू करने के
लिए पर्याप्त क्रेडिट नहीं हैं।
बॉडी त्रुटियुक्त फ़ील्ड नाम (या गैर-फ़ील्ड त्रुटियों के लिए
`detail`) द्वारा कुंजीबद्ध एक ऑब्जेक्ट है। इनपुट-सत्यापन विफलताओं
(उदा. अनुपलब्ध आवश्यक फ़ील्ड, अमान्य भाषा, अधिक आकार की पोर्ट्रेट
छवि) के लिए मान **स्ट्रिंग्स की एक ऐरे** होते हैं और सत्र बनाते समय
पाई गई विफलताओं (अज्ञात `workflow_id`, ब्लॉकलिस्ट किया गया
`vendor_data`, चेहरा मिलान वर्कफ़्लो के लिए कोई संदर्भ चेहरा उपलब्ध
नहीं) के लिए **सामान्य स्ट्रिंग** होते हैं। दोनों रूपों को संभालें।
content:
application/json:
schema:
type: object
additionalProperties: true
properties:
detail:
type: string
description: >-
गैर-फ़ील्ड त्रुटियों के लिए मानव-पठनीय त्रुटि संदेश (उदा.
अपर्याप्त क्रेडिट)। फ़ील्ड-स्तरीय विफलताएँ इसके बजाय कुंजी
के रूप में फ़ील्ड नाम का उपयोग करती हैं, जिसमें स्ट्रिंग
या स्ट्रिंग की सरणी वाला मान होता है।
example: >-
You don't have enough credits to perform this request.
Please top up at https://business.didit.me
examples:
Missing workflow_id:
summary: आवश्यक फ़ील्ड छोड़ा गया (स्ट्रिंग्स की सरणी का प्रारूप)
value:
workflow_id:
- This field is required.
Invalid workflow_id:
summary: अज्ञात workflow_id (साधारण-स्ट्रिंग स्वरूप)
value:
workflow_id: Invalid workflow_id.
Insufficient credits:
summary: संगठन के क्रेडिट समाप्त हो गए हैं
value:
detail: >-
You don't have enough credits to perform this request.
Please top up at https://business.didit.me
Blocklisted vendor_data:
summary: vendor_data ब्लॉकलिस्ट किया गया है
value:
vendor_data: >-
This user or business has been blocked and cannot create
new verification sessions.
Portrait image too large:
summary: portrait_image आकार सत्यापन में विफल रहता है
value:
portrait_image:
- Image size exceeds 2MB.
No stored face for vendor_data:
summary: >-
portrait_image के बिना और vendor_data उपयोगकर्ता के लिए बिना
किसी संग्रहीत चेहरे के चेहरा मिलान वर्कफ़्लो
value:
portrait_image: >-
No stored face image was found for this user. Send a
portrait_image, or complete an approved verification with
face liveness or an ID document for this vendor_data
first.
Portrait image required without vendor_data:
summary: >-
portrait_image के बिना और बिना vendor_data के चेहरा मिलान
वर्कफ़्लो
value:
portrait_image: >-
A portrait image is required to perform face match for
this workflow. Send a portrait_image, or provide the
vendor_data of a user with a previously stored face image
to reuse it.
'403':
description: >-
प्रमाणीकरण या प्राधिकरण विफल रहा। एक गलत, निरस्त या समय-सीमा समाप्त
कुंजी `401` लौटाती है। जब `x-api-key` हेडर मौजूद नहीं होता है या API
कुंजी मान्य होती है लेकिन क्लाइंट के पास इस एप्लिकेशन में सत्र बनाने
की अनुमति नहीं होती है (उदाहरण के लिए API कुंजी किसी भिन्न संगठन से
संबंधित है), तो endpoint `403` लौटाता है। ये विफलताएं `{"detail":
"You do not have permission to perform this action."}` बॉडी साझा
करती हैं। जांचें कि `x-api-key` हेडर मौजूद है और इच्छित एप्लिकेशन से
संबंधित है, यदि आवश्यक हो तो [Auth
API](/hi/auth-api/get-credentials) के माध्यम से एप्लिकेशन API कुंजी
पुनः प्राप्त करें, और पुनः प्रयास करें।
**हटाया गया एप्लिकेशन:** किसी एप्लिकेशन के हटाए जाने के कुछ मिनटों
तक, उसकी किसी API कुंजी से किया गया अनुरोध `{"detail": "This
application was deleted.", "code": "application_deleted"}` रिस्पॉन्स
दे सकता है। पुनः प्रयास न करें: एप्लिकेशन और उसकी API कुंजियाँ अब
मौजूद नहीं हैं। उन कुछ मिनटों के बाद, कुंजी को किसी भी अन्य अमान्य
कुंजी की तरह अस्वीकार कर दिया जाता है।
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: You do not have permission to perform this action.
code:
type: string
description: >-
मशीन-पठनीय कारण, केवल कुछ विफलताओं पर मौजूद।
`application_deleted`: API कुंजी उस एप्लिकेशन की है जिसे
हटा दिया गया था।
example: application_deleted
required:
- detail
examples:
Missing or invalid API key:
summary: कोई `x-api-key` हेडर नहीं या अमान्य API कुंजी
value:
detail: You do not have permission to perform this action.
No permission:
summary: क्लाइंट सत्र नहीं बना सकता
value:
detail: You do not have permission to perform this action.
Application deleted:
summary: हटाए गए एप्लिकेशन की API कुंजी
value:
detail: This application was deleted.
code: application_deleted
'429':
description: >-
रेट लिमिट पार हो गई — उसी API कुंजी / IP से 60-सेकंड की विंडो में
600 से अधिक सत्र-निर्माण अनुरोध। `Retry-After` का निरीक्षण करें और
पुनः प्रयास करने से पहले प्रतीक्षा करें।
**नोट:** स्रोत कोड `PAID_SESSION_RATE_LIMIT=600`
(`sessions/serializers/session.py`) के साथ 10 कॉल/मिनट की
`FREE_SESSION_RATE_LIMIT` भी परिभाषित करता है, लेकिन वह निःशुल्क
स्तर सीमा **इस V3 endpoint पर लागू नहीं होती है** — रेट लिमिट
मिडलवेयर प्लान की परवाह किए बिना 600/मिनट
`SESSION_CREATE_RATE_LIMIT` लागू करता है। 600/मिनट ही एकमात्र सीमा
है जिस तक आप यहाँ पहुँच सकते हैं।
headers:
Retry-After:
description: >-
अनुरोध का पुनः प्रयास करने से पहले कॉलर को जितने सेकंड प्रतीक्षा
करनी होगी।
schema:
type: integer
minimum: 1
example: 42
X-RateLimit-Limit:
description: >-
जिस सीमा का उल्लंघन हुआ था, उसके लिए वर्तमान 60-सेकंड की विंडो
में अनुमत अनुरोधों की अधिकतम संख्या (session-create के लिए 600)।
सैंडबॉक्स-कोटा वैरिएंट पर अनुपस्थित।
schema:
type: integer
example: 600
X-RateLimit-Remaining:
description: >-
उल्लंघन की गई सीमा के लिए वर्तमान विंडो में अभी भी अनुमत
अनुरोधों की संख्या। सैंडबॉक्स-कोटा संस्करण में अनुपस्थित।
schema:
type: integer
minimum: 0
example: 0
X-RateLimit-Reset:
description: >-
UTC epoch सेकंड जब वर्तमान रेट लिमिट विंडो रीसेट होती है।
sandbox-quota वैरिएंट पर अनुपस्थित।
schema:
type: integer
minimum: 0
example: 1747497600
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
रेट लिमिट उल्लंघन का मानव-पठनीय स्पष्टीकरण। तीन सीमाओं में
से कौन सी सीमा पार हुई है, यह पहचानने के लिए इस संदेश का
उपयोग करें।
example: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
examples:
Session-create limit:
summary: प्रति मिनट 600 से अधिक सत्र-निर्माण अनुरोध
value:
detail: >-
Session creation rate limit exceeded. You can make up to
600 requests per minute.
Sandbox session quota:
summary: >-
सैंडबॉक्स एप्लिकेशन ने 24 घंटों में 500 सत्रों की सीमा पार
कर ली
value:
detail: >-
Sandbox session quota exceeded (500 sessions per 24h).
Wait for the window to reset. Expected available in 3600
seconds.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: cURL
source: |-
curl -X POST 'https://verification.didit.me/v3/session/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"workflow_id": "11111111-2222-3333-4444-555555555555",
"vendor_data": "user-123",
"callback": "https://example.com/verification/callback",
"callback_method": "both",
"metadata": {"user_type": "premium", "account_id": "ABC123"},
"language": "en",
"contact_details": {
"email": "john.doe@example.com",
"send_notification_emails": true,
"email_lang": "en",
"phone": "+14155552671"
},
"expected_details": {
"first_name": "John",
"last_name": "Doe",
"date_of_birth": "1990-05-15",
"id_country": "USA",
"expected_document_types": ["P", "ID"]
}
}'
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.sessions.create(
workflow_id="11111111-2222-3333-4444-555555555555",
vendor_data="user-123",
callback="https://example.com/verification/callback",
callback_method="both",
metadata={"user_type": "premium", "account_id": "ABC123"},
language="en",
contact_details={
"email": "john.doe@example.com",
"send_notification_emails": True,
"email_lang": "en",
"phone": "+14155552671",
},
expected_details={
"first_name": "John",
"last_name": "Doe",
"date_of_birth": "1990-05-15",
"nationality": "USA",
"id_country": "USA",
"expected_document_types": ["P", "ID"],
},
)
print(result)
- lang: javascript
label: Node.js
source: |-
import Didit from "@didit-protocol/sdk-node";
// Reads DIDIT_API_KEY.
const didit = new Didit();
const result = await didit.sessions.create({
workflow_id: "11111111-2222-3333-4444-555555555555",
vendor_data: "user-123",
callback: "https://example.com/verification/callback",
callback_method: "both",
metadata: { user_type: "premium", account_id: "ABC123" },
language: "en",
contact_details: {
email: "john.doe@example.com",
send_notification_emails: true,
email_lang: "en",
phone: "+14155552671",
},
expected_details: {
first_name: "John",
last_name: "Doe",
date_of_birth: "1990-05-15",
nationality: "USA",
id_country: "USA",
expected_document_types: ["P", "ID"],
},
});
console.log(result);
- lang: go
label: Go
source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.Create(ctx, didit.SessionsCreateParams{\n\tWorkflowID: \"11111111-2222-3333-4444-555555555555\",\n\tVendorData: didit.String(\"user-123\"),\n\tCallback: didit.String(\"https://example.com/verification/callback\"),\n\tCallbackMethod: didit.Some(didit.SessionsCreateParamsCallbackMethod(\"both\")),\n\tMetadata: didit.Some[any](map[string]any{\"user_type\": \"premium\", \"account_id\": \"ABC123\"}),\n\tLanguage: didit.Some(didit.SessionsCreateParamsLanguage(\"en\")),\n\tContactDetails: didit.Some(didit.SessionsCreateParamsContactDetails{\n\t\tEmail: didit.String(\"john.doe@example.com\"),\n\t\tSendNotificationEmails: didit.Bool(true),\n\t\tEmailLang: didit.Some(didit.SessionsCreateParamsContactDetailsEmailLang(\"en\")),\n\t\tPhone: didit.String(\"+14155552671\"),\n\t}),\n\tExpectedDetails: didit.Some(didit.SessionsCreateParamsExpectedDetails{\n\t\tFirstName: didit.String(\"John\"),\n\t\tLastName: didit.String(\"Doe\"),\n\t\tDateOfBirth: didit.String(\"1990-05-15\"),\n\t\tNationality: didit.String(\"USA\"),\n\t\tIDCountry: didit.String(\"USA\"),\n\t\tExpectedDocumentTypes: didit.Some([]didit.SessionsCreateParamsExpectedDetailsExpectedDocumentTypes{\"P\", \"ID\"}),\n\t}),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)"
- lang: java
label: Java
source: |-
import java.time.LocalDate;
import java.util.List;
import java.util.Map;
import me.didit.Didit;
import me.didit.types.SessionsCreateParams;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result = client.sessions().create(SessionsCreateParams.builder()
.workflowId("11111111-2222-3333-4444-555555555555")
.vendorData("user-123")
.callback("https://example.com/verification/callback")
.callbackMethod(SessionsCreateParams.CallbackMethod.of("both"))
.metadata(Map.of("user_type", "premium", "account_id", "ABC123"))
.language(SessionsCreateParams.Language.of("en"))
.contactDetails(SessionsCreateParams.ContactDetails.builder()
.email("john.doe@example.com")
.sendNotificationEmails(true)
.emailLang(SessionsCreateParams.ContactDetails.EmailLang.of("en"))
.phone("+14155552671")
.build())
.expectedDetails(SessionsCreateParams.ExpectedDetails.builder()
.firstName("John")
.lastName("Doe")
.dateOfBirth(LocalDate.parse("1990-05-15"))
.nationality("USA")
.idCountry("USA")
.expectedDocumentTypes(List.of(SessionsCreateParams.ExpectedDetails.ExpectedDocumentTypes.of("P"), SessionsCreateParams.ExpectedDetails.ExpectedDocumentTypes.of("ID")))
.build())
.build());
System.out.println(result);
- lang: php
label: PHP
source: |-
sessions->create([
'workflow_id' => '11111111-2222-3333-4444-555555555555',
'vendor_data' => 'user-123',
'callback' => 'https://example.com/verification/callback',
'callback_method' => 'both',
'metadata' => ['user_type' => 'premium', 'account_id' => 'ABC123'],
'language' => 'en',
'contact_details' => [
'email' => 'john.doe@example.com',
'send_notification_emails' => true,
'email_lang' => 'en',
'phone' => '+14155552671',
],
'expected_details' => [
'first_name' => 'John',
'last_name' => 'Doe',
'date_of_birth' => '1990-05-15',
'nationality' => 'USA',
'id_country' => 'USA',
'expected_document_types' => ['P', 'ID'],
],
]);
print_r($result->toArray());
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.sessions.create(
workflow_id: "11111111-2222-3333-4444-555555555555",
vendor_data: "user-123",
callback: "https://example.com/verification/callback",
callback_method: "both",
metadata: { user_type: "premium", account_id: "ABC123" },
language: "en",
contact_details: {
email: "john.doe@example.com",
send_notification_emails: true,
email_lang: "en",
phone: "+14155552671",
},
expected_details: {
first_name: "John",
last_name: "Doe",
date_of_birth: "1990-05-15",
nationality: "USA",
id_country: "USA",
expected_document_types: ["P", "ID"],
}
)
puts result.to_h
- lang: csharp
label: .NET
source: >-
using System;
using System.Collections.Generic;
using System.Text.Json;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var result = await client.Sessions.CreateAsync(new
SessionsCreateParams
{
WorkflowId = "11111111-2222-3333-4444-555555555555",
VendorData = "user-123",
Callback = "https://example.com/verification/callback",
CallbackMethod = new SessionsCreateParamsCallbackMethod("both"),
Metadata = new Dictionary { ["user_type"] = "premium", ["account_id"] = "ABC123" },
Language = new SessionsCreateParamsLanguage("en"),
ContactDetails = new SessionsCreateParamsContactDetails
{
Email = "john.doe@example.com",
SendNotificationEmails = true,
EmailLang = new SessionsCreateParamsContactDetailsEmailLang("en"),
Phone = "+14155552671",
},
ExpectedDetails = new SessionsCreateParamsExpectedDetails
{
FirstName = "John",
LastName = "Doe",
DateOfBirth = "1990-05-15",
Nationality = "USA",
IdCountry = "USA",
ExpectedDocumentTypes = new SessionsCreateParamsExpectedDetailsExpectedDocumentTypes[] { "P", "ID" },
},
});
Console.WriteLine(JsonSerializer.Serialize(result));
components:
schemas:
SessionSignDocument:
type: object
required:
- file_name
- content_base64
properties:
title:
type: string
minLength: 1
maxLength: 255
description: >-
हस्ताक्षरकर्ता को दिखाया जाने वाला शीर्षक। डिफ़ॉल्ट रूप से
`file_name` होता है।
file_name:
type: string
minLength: 1
maxLength: 255
description: फ़ाइल का नाम, जो `.pdf` या `.docx` पर समाप्त होता है।
content_base64:
type: string
format: byte
description: >-
फ़ाइल, base64-एन्कोडेड। एक PDF बिना पासवर्ड, स्क्रिप्ट या संलग्न
फ़ाइलों के 20 MB और 100 पृष्ठों तक की हो सकती है। एक Word फ़ाइल
(`.docx`) 20 MB तक की हो सकती है और अनुरोध चलने के दौरान अधिकतम 25
सेकंड में PDF में परिवर्तित हो जाती है; इसके बाद PDF की सीमाएँ समान
होती हैं। प्रति सत्र अधिकतम 5 Word फ़ाइलें। मैक्रोज़, ट्रैक किए गए
परिवर्तनों, बाहरी सामग्री के लिंक या एम्बेडेड ऑब्जेक्ट वाली Word
फ़ाइल को `signature_document_not_supported` के साथ अस्वीकार कर दिया
जाता है, और जिसे परिवर्तित नहीं किया जा सकता है वह
`signature_document_conversion_failed` लौटाता है, प्रत्येक एक
`reason` के साथ।
fields:
type: array
description: >-
इस दस्तावेज़ पर रखने के लिए वैकल्पिक फ़ील्ड, 200 तक। पेज और
स्थितियां PDF, या Word फ़ाइल के लिए कनवर्ट किए गए PDF को संदर्भित
करती हैं। फ़ील्ड के बिना, हस्ताक्षरकर्ता दस्तावेज़ पढ़ता है और उससे
सहमत होता है।
items:
$ref: '#/components/schemas/SignatureField'
maxItems: 200
SignatureField:
type: object
description: >-
सत्र दस्तावेज़ पर रखने के लिए एक फ़ील्ड: कौन सा हस्ताक्षरकर्ता इसे भरता
है, कैसे, और कहाँ। या तो स्थिति (`page`, `x`, `y`, `width` और `height`)
दें या फिर `anchor`। स्थितियाँ प्रदर्शित किए गए पेज के अंश होती हैं,
उसके ऊपरी-बाएँ कोने से, 4 दशमलव स्थानों तक राउंड की गई, और फ़ील्ड पेज के
अंदर फ़िट होनी चाहिए। एक दस्तावेज़ अधिकतम 200 फ़ील्ड ले सकता है और एक
हस्ताक्षरकर्ता अधिकतम 500, और दस्तावेज़ पर फ़ील्ड वाली प्रत्येक भूमिका
के लिए वहाँ एक `signature` या `initials` फ़ील्ड की आवश्यकता होती है।
[दस्तावेज़ पर
फ़ील्ड](/hi/core-technology/electronic-signature/overview#दस्तावेज़-पर-फ़ील्ड)
देखें।
required:
- key
- type
properties:
key:
type: string
pattern: ^[a-z][a-z0-9_]{0,63}$
description: >-
परिणामों और `sign.field_values` में फ़ील्ड का नाम बताता है।
दस्तावेज़ के भीतर अद्वितीय।
type:
type: string
enum:
- signature
- initials
- full_name
- date_signed
- text
- checkbox
- email
- data
description: >-
फ़ील्ड में क्या समाहित है। हस्ताक्षरकर्ता अपने अपनाए हुए `signature`
और `initials` लागू करता है, `text` टाइप करता है, `checkbox` पर टिक
करता है, और सत्र में कोई सत्यापित ईमेल न होने पर `email` टाइप करता
है। Didit `full_name` (सत्यापित नाम), `date_signed` (हस्ताक्षर करने
की तिथि, हस्ताक्षरकर्ता के समय क्षेत्र में), `data` (`prefill` से)
और एक सत्यापित `email` भरता है, और उन्हें केवल-पढ़ने के लिए दिखाता
है। कोई दिनांक पिकर प्रकार नहीं है: `text` का उपयोग करें।
role:
type: string
enum:
- verified_person
- legal_representative
- key_people
description: >-
`signature_signer` मानों के साथ फ़ील्ड कौन भरता है। एक चरण केवल अपने
हस्ताक्षरकर्ता के फ़ील्ड भरता है और स्टैम्प करता है। डिफ़ॉल्ट रूप से
चरण का हस्ताक्षरकर्ता।
page:
type: integer
minimum: 1
description: >-
पेज संख्या, 1 से दस्तावेज़ की पेज संख्या तक। Word दस्तावेज़ के लिए,
कनवर्ट किए गए PDF का एक पेज।
x:
type: number
minimum: 0
maximum: 1
description: बायाँ किनारा, पेज की चौड़ाई के एक अंश के रूप में।
'y':
type: number
minimum: 0
maximum: 1
description: पेज की ऊंचाई के एक अंश के रूप में ऊपरी किनारा।
width:
type: number
minimum: 0.02
maximum: 1
description: >-
पेज की चौड़ाई के अंश के रूप में चौड़ाई। हस्ताक्षर कम से कम `0.12`
चौड़ा होता है।
height:
type: number
minimum: 0.012
maximum: 1
description: >-
ऊंचाई, पेज की ऊंचाई के एक अंश के रूप में। हस्ताक्षर कम से कम `0.035`
ऊंचा होता है।
anchor:
$ref: '#/components/schemas/SignatureFieldAnchor'
required:
type: boolean
description: >-
`signature` and `initials` are required unless you set `false`.
`full_name`, `date_signed` and `data` are always required. The
signer can't finish a document until its required fields have a
value, and a required checkbox must be ticked.
label:
type: string
minLength: 1
maxLength: 80
description: >-
हस्ताक्षरकर्ता को और परिणामों में दिखाया जाता है। प्रकार के आधार पर
डिफ़ॉल्ट होता है।
placeholder:
type: string
nullable: true
maxLength: 80
description: केवल `text` और `email`।
validation:
$ref: '#/components/schemas/SignatureFieldValidation'
prefill:
type: string
nullable: true
description: >-
मान कहाँ से आता है: `identity.full_name`, `identity.first_name`,
`identity.last_name`, `identity.date_of_birth` (`DD/MM/YYYY`),
`identity.nationality`, `identity.document_number`,
`identity.document_type`, `identity.issuing_country`,
`identity.address`, `contact.email`, `contact.phone`,
`company.name`, `company.registration_number`, `company.address`,
`company.country` (KYB), `session.vendor_data`, `metadata.`
(सत्र के `metadata` की एक कुंजी) या `api.` (`sign.field_values`
की एक कुंजी)। `data` के लिए आवश्यक। `full_name` हमेशा
`identity.full_name` का उपयोग करता है और `email`, `contact.email` का
उपयोग करता है। जब हस्ताक्षरकर्ता हस्ताक्षर करना शुरू करता है, तो
`data`, `full_name` और सत्यापित `email` फ़ील्ड के मान तय हो जाते
हैं।
editable_when_prefilled:
type: boolean
default: false
description: >-
केवल `text` और `email`: हस्ताक्षरकर्ता पहले से भरे हुए मान को बदल
सकता है।
checked_by_default:
type: boolean
default: false
description: 'केवल `checkbox`: बॉक्स पहले से टिक किया हुआ शुरू होता है।'
date_format:
type: string
enum:
- DD/MM/YYYY
- MM/DD/YYYY
- YYYY-MM-DD
- D MMMM YYYY
default: DD/MM/YYYY
description: केवल `date_signed`।
SignatureFieldAnchor:
type: object
description: >-
दस्तावेज़ में किसी स्थिति के बजाय टेक्स्ट के एक भाग के आधार पर फ़ील्ड
रखता है। Didit PDF से टेक्स्ट को नहीं हटाता है, इसलिए इसे पेज के
बैकग्राउंड के समान रंग में लिखें। जब टेक्स्ट नहीं मिलता है, तो कॉल
`field_anchor_not_found` के साथ `400` लौटाती है। [एंकर टेक्स्ट द्वारा
फ़ील्ड
रखें](/hi/sessions-api/create-session#एंकर-टेक्स्ट-से-फ़ील्ड-लगाएँ)
देखें।
required:
- text
properties:
text:
type: string
minLength: 1
maxLength: 64
description: >-
दस्तावेज़ में खोजा गया टेक्स्ट। Word फ़ाइल के लिए, कनवर्ट की गई PDF
में।
occurrence:
type: string
enum:
- first
- all
default: first
description: >-
`all` प्रत्येक मिलान के लिए एक फ़ील्ड रखता है; पहले के बाद की
कुंजियों को `_2`, `_3` आदि मिलते हैं।
offset_x:
type: number
description: >-
टेक्स्ट के बाएं किनारे में जोड़ा गया, पेज की चौड़ाई के अंश के रूप
में।
offset_y:
type: number
description: >-
टेक्स्ट के शीर्ष किनारे में जोड़ा गया, पेज की ऊंचाई के अंश के रूप
में।
width:
type: number
minimum: 0.02
maximum: 1
description: पेज की चौड़ाई के अंश के रूप में, फ़ील्ड की चौड़ाई।
height:
type: number
minimum: 0.012
maximum: 1
description: फ़ील्ड की ऊंचाई, पेज की ऊंचाई के एक अंश के रूप में।
SignatureFieldValidation:
type: object
nullable: true
description: >-
`text` फ़ील्ड के मान के लिए नियम। कंसोल पूर्वावलोकन, हस्ताक्षर प्रक्रिया
और API समान नियम लागू करते हैं।
properties:
kind:
type: string
enum:
- any
- letters
- number
- email
- pattern
description: >-
`letters`: किसी भी लिपि में अक्षर, स्पेस, हाइफ़न और एपॉस्ट्रॉफ़ी।
`number`: वैकल्पिक दशमलव विभाजक के साथ अंक। `pattern`: मान `pattern`
से मेल खाना चाहिए।
min_length:
type: integer
minimum: 0
maximum: 500
description: '`0` से लेकर `max_length` तक।'
max_length:
type: integer
minimum: 1
maximum: 500
default: 120
pattern:
type: string
nullable: true
minLength: 1
maxLength: 200
description: >-
`kind: "pattern"` के साथ आवश्यक है। एक रेगुलर एक्सप्रेशन जिससे पूरा
मान मेल खाना चाहिए। लुकअराउंड और बैकरिफ़रेंस समर्थित नहीं हैं।
message:
type: string
nullable: true
maxLength: 120
description: डिफ़ॉल्ट त्रुटि के बजाय हस्ताक्षरकर्ता को दिखाया गया।
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
आपकी एप्लिकेशन की API कुंजी, Business Console में Developers -> API keys
से। प्राथमिक कुंजी के पास पूर्ण एक्सेस होता है। एक नामित कुंजी को स्कोप
किया जा सकता है: प्रति संसाधन none, read या write, कुछ वर्कफ़्लो या
स्वीकृत सत्रों तक सीमित, IP पतों की सूची तक सीमित, और समाप्ति तिथि तक
सीमित। 401 का अर्थ है कि कुंजी गलत है, निरस्त कर दी गई है या उसकी
समय-सीमा समाप्त हो गई है; 403 का अर्थ है कि कोई कुंजी नहीं भेजी गई थी,
कुंजी के पास इस संसाधन या कार्रवाई का एक्सेस नहीं है, या अनुरोध उसकी IP
सूची से बाहर के पते से आया था; सत्र रूट पर 404 का अर्थ है कि सत्र कुंजी
के वर्कफ़्लो या स्थितियों से बाहर है। मीडिया एक्सेस के बिना एक कुंजी को
छवि, वीडियो और PDF URL null के रूप में प्राप्त होते हैं, और सत्र write
के बिना एक कुंजी को सत्र लिंक और token null के रूप में प्राप्त होते हैं।
देखें https://docs.didit.me/console/api-keys।
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.