> ## 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 API अनुरोध

> Didit API अनुरोधों को x-api-key हेडर में कुंजी से प्रमाणित करें। गलत/समाप्त कुंजी पर 401 व अनुपलब्ध कुंजी पर 403 मिलता है।



API प्रमाणीकरण प्रॉम्प्ट
        प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें



      
      

\<pre>

\````# Goal — authenticate against Didit's REST API

Two hosts, two auth schemes. Never mix them up.

\## Host map

\| Host | Surface | Auth header |
\|---|---|---|
\| `https://verification.didit.me` | Verification API — sessions, workflows, entities, transactions, standalone APIs, lists, webhooks, billing (every `/v3/...` route) | `x-api-key: <DIDIT_API_KEY>` |
\| `https://apx.didit.me` | Account / organization / application management (`/auth/v2/programmatic/...`, `/auth/v2/organizations/...`) | `Authorization: Bearer <JWT access_token>` |

The verification API does **not** use OAuth Bearer tokens. It uses a long-lived API key on the `x-api-key` header. Treat the key as a server-side secret — never ship it to a browser or mobile bundle.

\## How to obtain the api_key (no console UI needed)

\<Warning>
Substitute `you@yourdomain.com` below with a real inbox. The register endpoint sends the verification code synchronously, so reserved test domains (`@example.com`, `@example.org`, `@*.test`, `@*.example`, `@*.invalid`) get refused by mail delivery and the call returns a `500`.
\</Warning>

\```bash
\# 1) Register — emails a 6-char code (15 min TTL).
\#    Password rules: ≥8 chars, 1 uppercase, 1 lowercase, 1 digit, 1 special.
curl -X POST https://apx.didit.me/auth/v2/programmatic/register/ \
-H "Content-Type: application/json" \
-d '{"email": "you@yourdomain.com", "password": "StrongP@ss1"}'

\# 2) Verify email — returns api_key inline.
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 -> { access_token, refresh_token, organization, application: { api_key, client_id, uuid } }
\```

Persist `response.application.api_key` as the env var `DIDIT_API_KEY`.
New keys start with `sk_live_` (live application) or `sk_test_` (sandbox application), followed by 43 URL-safe characters.
Keys created before this format have no prefix and keep working, so never validate a key by its prefix.

\## Recover the key (lost it)

\```bash
\# Log back in to get a fresh JWT
TOK=$(curl -s -X POST https://apx.didit.me/auth/v2/programmatic/login/ \
-H "Content-Type: application/json" \
-d '{"email":"you@yourdomain.com","password":"StrongP@ss1"}' | jq -r .access_token)

\# Find your org and app
curl https://apx.didit.me/auth/v2/organizations/me/ -H "Authorization: Bearer $TOK"
curl https://apx.didit.me/auth/v2/organizations/me/$ORG_ID/applications/$APP_ID/ \
-H "Authorization: Bearer $TOK"
\# Response.api_key is your key.
\```

\## Calling the verification API

\```bash
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"workflow_id":"<WORKFLOW_ID>","vendor_data":"user-42","callback":"https://myapp.com/return"}'
\```

\## Failure modes

\| Status | Meaning | Fix |
\|---|---|---|
\| `401` on verification.didit.me | `x-api-key` header wrong, malformed, revoked or expired | Re-fetch via the recover-key flow above, or use a key that has not expired |
\| `403` on verification.didit.me | No `x-api-key` header, a scoped key without access to this resource or action, or a key called from an address outside its IP list | Use a key with that access (Developers -> API keys in the console) |
\| `403` with `"code": "application_deleted"` on verification.didit.me | The key's application was deleted. You get this for a few minutes after the deletion; after that the key is refused like any invalid key | Do not retry: the application and its keys no longer exist. Use a key of an application that exists |
\| `404` on a session route | The session is outside the scoped key's workflows or statuses | Use a key whose limits include that session |
\| `403` on apx.didit.me | JWT `Authorization` header missing or expired | Call `POST /auth/v2/programmatic/login/` again |
\| `429` | Rate limit; response includes a `wait` field (seconds) | Back off, then retry |

\## Sources of truth
\- /openapi-auth.json — every account / org / app endpoint
\- /openapi-25.json — every verification endpoint
\- /integration/integration-prompt — end-to-end integration recipe````

\</pre>



      
      

यहाँ पेस्ट करें

## अपनी API कुंजी ढूँढनाDidit में, API कुंजियाँ आपके खाते के भीतर एक विशिष्ट **एप्लिकेशन** के लिए स्कोप्ड होती हैं। एक एप्लिकेशन एक वर्कस्पेस है जहाँ आप किसी विशेष प्रोजेक्ट या एनवायरनमेंट के लिए वर्कफ़्लो कॉन्फ़िगर कर सकते हैं और सत्यापन प्रबंधित कर सकते हैं।प्रत्येक एप्लिकेशन बनाते समय उसे पूर्ण एक्सेस वाली एक प्राइमरी API कुंजी मिलती है। आप इसके साथ और भी कुंजियाँ जोड़ सकते हैं, जिनमें से प्रत्येक के पास केवल वही एक्सेस होगा जिसकी किसी सेवा या पार्टनर को आवश्यकता है। अपनी कुंजियाँ ढूँढने के लिए:**1. Business Console में लॉग इन करें**[**Didit Business Console**](https://business.didit.me) पर जाएँ और साइन इन करें।**2. अपना एप्लिकेशन चुनें**शीर्ष पर स्थित ड्रॉपडाउन मेनू से वह **एप्लिकेशन** चुनें जिसके साथ आप काम करना चाहते हैं।**3. API कुंजियाँ खोलें**बाईं ओर के साइडबार में **डेवलपर -> API कुंजियाँ** पर नेविगेट करें।**4. कुंजी कॉपी करें या बनाएँ****प्राइमरी** कुंजी एप्लिकेशन का अपना सीक्रेट है। किसी सेवा या पार्टनर को उसकी ज़रूरत के अनुसार एक्सेस के साथ उसका अपना सीक्रेट देने के लिए एक नई कुंजी बनाएँ।> [!WARNING]
>
> **आपकी API कुंजी एक सीक्रेट है — इसे पासवर्ड की तरह समझें।**
>
> प्राइमरी कुंजी आपके एप्लिकेशन की ओर से API तक पूर्ण एक्सेस प्रदान करती है। इसे कभी भी फ़्रंटएंड कोड, सार्वजनिक रिपॉजिटरी या क्लाइंट-साइड बंडल में उजागर न करें। इसे हमेशा केवल सर्वर-साइड रखें।### API कुंजी फ़ॉर्मेटनई API कुंजियाँ लाइव एप्लिकेशन के लिए `sk_live_` या सैंडबॉक्स एप्लिकेशन के लिए `sk_test_` से शुरू होती हैं, जिसके बाद 43 URL-सुरक्षित वर्ण (अक्षर, अंक, `-` और `_`) होते हैं।
इस फ़ॉर्मेट से पहले बनाई गई कुंजियों में कोई प्रीफ़िक्स नहीं होता है और वे बिना किसी बदलाव के काम करती रहती हैं।
`x-api-key` हेडर में प्रीफ़िक्स सहित पूरी कुंजी भेजें, और किसी कुंजी को सिर्फ़ इसलिए अस्वीकार न करें क्योंकि उसमें कोई प्रीफ़िक्स नहीं है।## अपना संगठन ID ढूँढेंआपका **संगठन ID** वह UUID है जो आपके संगठन की पहचान करता है। आप इसका उपयोग संगठन-स्कोप्ड API पाथ जैसे `/auth/v2/organizations/me/{org_id}/applications/` में करते हैं। आप इसे बिना किसी API कॉल की आवश्यकता के सीधे Business Console से कॉपी कर सकते हैं:**1. संगठन सेटिंग्स खोलें**[**Didit Business Console**](https://business.didit.me) में, **संगठन सेटिंग्स** पर जाएँ।**2. संगठन ID कॉपी करें****संगठन ID** फ़ील्ड संगठन के नाम के आगे आपके संगठन का UUID दिखाता है, जिसमें क्लिपबोर्ड पर कॉपी करने का बटन होता है।***## प्रमाणीकृत अनुरोध करनाकिसी API अनुरोध को प्रमाणित करने के लिए, `x-api-key` HTTP हेडर में अपनी सीक्रेट API कुंजी शामिल करें।यहाँ `Create Session` endpoint पर एक प्रमाणीकृत अनुरोध का उदाहरण दिया गया है:```shell cURL theme={null}
curl --request POST \
     --url https://verification.didit.me/v3/session/ \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'x-api-key: YOUR_API_KEY' \
     --data '
{
  "workflow_id": "WORKFLOW_ID",
  "vendor_data": "USER_ID",
  "callback": "CALLBACK_URL"
}
'
```***## एरर हैंडलिंगयदि आपकी API कुंजी गलत, विकृत या निरस्त है, तो API `401 Unauthorized` लौटाता है:```json theme={null}
{
  "detail": "Authentication credentials were not provided or are invalid."
}
```समय-सीमा समाप्त कुंजी भी `"detail": "This API key has expired."` के साथ `401` लौटाती है।
बिना कुंजी वाला अनुरोध `"detail": "You do not have permission to perform this action."` के साथ `403` लौटाता है।| स्टेटस कोड | अर्थ |
| - | - |
| **401** | API कुंजी गलत, विकृत, निरस्त या समय-सीमा समाप्त है |
| **403** | कोई API कुंजी नहीं भेजी गई थी, कुंजी के पास अनुरोधित संसाधन या कार्रवाई का एक्सेस नहीं है, या अनुरोध कुंजी की IP सूची से बाहर के पते से आया है |
| **403** `"code": "application_deleted"` के साथ | कुंजी उस एप्लिकेशन की है जिसे हटा दिया गया था। हटाए जाने के कुछ मिनटों तक API इसका रिस्पॉन्स देता है, फिर किसी भी अमान्य कुंजी की तरह इस कुंजी को अस्वीकार कर देता है। पुनः प्रयास न करें: एप्लिकेशन और उसकी कुंजियाँ अब मौजूद नहीं हैं। |
| **404** | सत्र रूट पर: सत्र कुंजी के वर्कफ़्लो या स्थितियों के बाहर है |[API एरर](https://docs.didit.me/hi/integration/api-errors.md) पेज हर स्टेटस, बॉडी और कोड को सूचीबद्ध करता है।***## स्कोप्ड API कुंजियाँप्राइमरी कुंजी साझा करने के बजाय प्रत्येक सेवा या पार्टनर को उसकी अपनी कुंजी दें।
प्रत्येक कुंजी का अपना एक्सेस होता है: प्रत्येक संसाधन (सत्र, निर्णय, मीडिया, लोग, कंपनियाँ, लेन-देन, वर्कफ़्लो, webhook, एप्लिकेशन सेटिंग्स, एनालिटिक्स) के लिए कोई एक्सेस नहीं, पढ़ने या लिखने का एक्सेस; साथ ही, कुछ वर्कफ़्लो तक, केवल स्वीकृत सत्रों तक, IP पतों की सूची तक और समाप्ति तिथि तक पहुँच सीमित करने के वैकल्पिक विकल्प होते हैं।
आप 24 घंटे के ओवरलैप के साथ कुंजी को रोटेट कर सकते हैं, और इसे तुरंत निरस्त कर सकते हैं।स्कोप्ड एक्सेस उपलब्ध होने से पहले बनाई गई कुंजियों के पास पूर्ण एक्सेस बना रहता है।प्रीसेट, प्रत्येक द्वारा कवर किए जाने वाले संसाधनों, और API द्वारा स्कोप्ड कुंजी का रिस्पॉन्स कैसे दिया जाता है, इसके लिए [API कुंजियाँ](https://docs.didit.me/hi/console/api-keys.md) देखें।> [!TIP]
>
> यदि आपको `401` एरर प्राप्त होता है, तो दोबारा जाँच लें कि आप सही एप्लिकेशन के लिए सही API कुंजी का उपयोग कर रहे हैं और इसे फिर से जनरेट नहीं किया गया है।


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