> ## 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.

# वेंडर डेटा लिंकिंग: ID को एंटिटी से जोड़ें

> vendor_data पहचानकर्ता आपके सिस्टम को Didit से जोड़ता है, सत्र, लेन-देन और उपयोगकर्ता/व्यवसाय एंटिटी को एक प्रोफ़ाइल में बाँधता है। प्रति कॉल भुगतान।

विक्रेता डेटा लिंकिंग प्रॉम्प्ट
प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें

<pre>
  \`\`\`\`# Goal — link every session, transaction, and entity together using `vendor_data`

  `vendor_data` is the string identifier you choose and pass on every API call to bind it to a persistent [User](https://docs.didit.me/entities/users/overview.md) or [Business](https://docs.didit.me/entities/businesses/overview.md) entity. Get this right once and you never have to re-key history afterwards.

  ## Rules

  * `vendor_data` is **opaque** to Didit. Use your stable internal customer id.
  * Choose one canonical id per entity and never change it. Changing it orphans history under a new entity.
  * Prefix by entity type when convenient (`user_...`, `biz_...`) to avoid collisions in your own code.
  * Keep it under 128 chars, case-sensitive stable. Hard limit is 2000 bytes (UTF-8 encoded) - anything over that is rejected with a 400 rather than accepted.
  * **Never put raw PII in it** — it surfaces in webhooks, logs, and API responses.
  * Uniqueness is per application × entity type. User `user-42` and Business `user-42` are different entities (but don't do this).

  ## Where it goes

  | API | Field |
  | - | - |
  | `POST /v3/session/` | top-level `vendor_data` (KYC and KYB) |
  | `POST /v3/transactions/` | top-level `vendor_data` and `applicant.vendor_data` / `counterparty.vendor_data` |
  | `POST /v3/users/create/` / `POST /v3/businesses/create/` | `vendor_data` |
  | `GET /v3/sessions?vendor_data=...` | query param to retrieve history |
  | `GET /v3/users/{vendor_data}/` / `GET /v3/businesses/{vendor_data}/` | path param |

  ## Pattern — pre-create the entity, then run a session

  ```bash
  # 1) Seed the entity with metadata before any session
  curl -X POST https://verification.didit.me/v3/users/create/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "vendor_data": "user-42",
  "display_name": "Jane Doe",
  "metadata": {"tier": "premium", "signup_date": "2026-04-01"}
  }'

  # 2) Run a KYC session linked to the same entity
  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"
  }'

  # 3) Later, retrieve every session for the entity
  curl -G https://verification.didit.me/v3/sessions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  --data-urlencode "vendor_data=user-42"
  ```

  ## Auto-create semantics

  If you create a session with a new `vendor_data` and no entity exists, Didit creates the entity automatically with `status: ACTIVE` and links the session.

  ## Failure modes

  * Missing `vendor_data` on session create → session is orphaned, won't appear in any entity profile, cannot be filtered by `vendor_data` later (only by `session_id`).
  * Different case (`User-42` vs `user-42`) → two separate entities. Pick a casing convention and stick to it.
  * Same `vendor_data` across staging and prod apps → no collision; `vendor_data` is scoped per application.

  ## Sources of truth

  * /entities/users/operations — full User CRUD
  * /entities/businesses/operations — full Business CRUD
  * /sessions-api/create-session — session body shape
  * /integration/integration-prompt — canonical end-to-end prompt\`\`\`\`
</pre>

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

`vendor_data` वह पहचानकर्ता है जो आप हर सत्र और लेन-देन के साथ भेजते हैं ताकि उसे [उपयोगकर्ता](https://docs.didit.me/hi/entities/users/overview.md) या [व्यवसाय](https://docs.didit.me/hi/entities/businesses/overview.md) इकाई से जोड़ा जा सके। इकाई एकत्रीकरण के लिए यह सबसे महत्वपूर्ण फ़ील्ड है। इसे सही रखने पर, प्रोफ़ाइल इतिहास, लेन-देन निगरानी, ब्लॉकलिस्ट प्रवर्तन और सतत AML निगरानी जैसी इसके बाद की सभी सुविधाएँ सहजता से काम करती हैं।

## यह क्या है

`vendor_data` एक **स्ट्रिंग** है जिसे आप चुनते हैं। Didit इसे एक अपारदर्शी पहचानकर्ता मानता है और इसकी सामग्री की व्याख्या नहीं करता। सामान्य मान इस प्रकार हैं:

| आपका सिस्टम | उपयुक्त `vendor_data` मान |
| - | - |
| आंतरिक उपयोगकर्ता डेटाबेस | `user_1234`, उपयोगकर्ता का `uuid-v4` |
| ग्राहक-मुखी ID | `CUST-2026-00042`, हैश किया गया ईमेल |
| मल्टी-टेनेंट SaaS | `tenant_acme:user_1234` |
| B2B प्लेटफ़ॉर्म | `company-hq-global`, `tax-id-US-123456789` |

> [!WARNING]
>
> `vendor_data` में **कभी** PII (ईमेल, फ़ोन नंबर, कच्ची कर पहचान संख्याएँ) सीधे न डालें। उन्हें हैश करें या प्रीफ़िक्स लगाएँ। `vendor_data` webhook payload में दिखता है और जब तक इकाई मौजूद है, तब तक अनिश्चित काल तक संग्रहीत रहता है।

## यह चीज़ों को कैसे जोड़ता है

```mermaid theme={null}
flowchart TD
    subgraph YourSystem["Your system"]
      Customer["Customer record: user-42"]
    end
    subgraph Didit["Didit platform"]
      Entity["User entity (vendor_data = user-42)"]
      S1[Session #1]
      S2[Session #2]
      T1[Transaction #1]
      T2[Transaction #2]
      F[Face biometric]
    end
    Customer -.vendor_data.-> Entity
    S1 --> Entity
    S2 --> Entity
    T1 --> Entity
    T2 --> Entity
    F --> Entity
```

जब आप `vendor_data` मान के साथ सत्र या लेन-देन सबमिट करते हैं:

1. Didit आपके एप्लिकेशन में उस `vendor_data` वाली इकाई को खोजता है।
2. यदि वह मौजूद है, तो नई वस्तु उस इकाई से जुड़ जाती है।
3. यदि वह मौजूद नहीं है, तो Didit इकाई बनाता है (`status: ACTIVE` के साथ) और नई वस्तु को उससे जोड़ता है।

यह इन पर लागू होता है:

* `POST /v3/session/`: KYC और व्यवसाय सत्यापन (KYB) सत्र
* `POST /v3/transactions/`: लेन-देन (आवेदक और प्रतिपक्ष, दोनों के लिए)
* लेन-देन payloads के भीतर `applicant.vendor_data` / `counterparty.vendor_data` फ़ील्ड

## विशिष्टता और दायरा

`vendor_data` **प्रति एप्लिकेशन अद्वितीय** है, न कि Didit में वैश्विक रूप से:

| दायरा | विशिष्टता की गारंटी |
| - | - |
| एक एप्लिकेशन के भीतर | `vendor_data` प्रति इकाई प्रकार अद्वितीय है (उपयोगकर्ता और व्यवसाय अलग नेमस्पेस हैं) |
| आपके संगठन के अलग-अलग एप्लिकेशन | `vendor_data` साझा **नहीं** होता। दो एप्लिकेशन में एक ही मान दो अलग इकाइयों को दर्शाता है |
| अलग-अलग संगठन | साझा नहीं होता। हर संगठन की अपनी इकाई तालिकाएँ होती हैं |

इसका अर्थ है कि आप स्टेजिंग एप्लिकेशन और प्रोडक्शन एप्लिकेशन में एक ही `vendor_data` का उपयोग बिना टकराव के कर सकते हैं। और आप एक उपयोगकर्ता `user-42` और एक व्यवसाय `user-42` रख सकते हैं, बिना टकराव के, हालाँकि स्पष्टता के लिए इसकी सलाह नहीं दी जाती।

## यदि आप `vendor_data` छोड़ देते हैं तो क्या होता है

आप `vendor_data` के बिना सत्र बना सकते हैं। ऐसे में:

* सत्र के लिए कोई इकाई नहीं बनती।
* सत्र अलग-थलग रहता है और किसी भी उपयोगकर्ता या व्यवसाय प्रोफ़ाइल में नहीं दिखेगा।
* आप बाद में `vendor_data` से सत्र नहीं खोज सकते, केवल `session_id` से।

इस पैटर्न का उपयोग केवल उन गुमनाम या एक-बार किए जाने वाले सत्यापनों के लिए करें जहाँ इकाई एकत्रीकरण की ज़रूरत नहीं है। हर उस इंटीग्रेशन के लिए जिसमें पुनः सत्यापन, लेन-देन या सतत निगरानी शामिल है, हमेशा `vendor_data` दें।

## उदाहरण: पहले इकाई बनाएँ, फिर सत्र चलाएँ

```bash theme={null}
# 1. Pre-create the User with initial metadata
curl -X POST https://verification.didit.me/v3/users/create/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data": "user-42",
    "display_name": "Jane Doe",
    "metadata": { "tier": "premium", "signup_date": "2026-04-01" }
  }'

# 2. Create a User Verification (KYC) session for the same user
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "wf_kyc_standard",
    "vendor_data": "user-42"
  }'

# 3. Later, submit a transaction tied to the same user
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "txn_id": "tx-0001",
    "direction": "OUTBOUND",
    "amount": "500.00",
    "currency": "EUR",
    "applicant": { "vendor_data": "user-42" },
    "counterparty": { "name": "Acme Corp" }
  }'
```

तीनों कॉल एक ही उपयोगकर्ता इकाई से जुड़ी हैं। जब आप बाद में `GET /v3/users/user-42/` कॉल करेंगे, तो आपको सत्र गणना, स्वीकृत/अस्वीकृत काउंटर, जुड़े लेन-देन और नवीनतम प्रोफ़ाइल डेटा दिखेगा।

## बाहरी ID का माइग्रेशन

यदि आप किसी मौजूदा KYC विक्रेता से Didit पर आ रहे हैं, तो पहले दिन से अपनी मौजूदा स्थिर उपयोगकर्ता ID को `vendor_data` के रूप में भेजें। इससे यह आसान होता है:

* Didit डेटा को अपने आंतरिक डेटाबेस से मिलाना।
* कोई भी सत्र चलाने से पहले कंसोल CSV इंपोर्ट के ज़रिए ऐतिहासिक उपयोगकर्ताओं को बल्क में लोड करना।
* बाद में लेन-देन निगरानी के लिए Didit पर माइग्रेट करते समय संबंध बनाए रखना।

## नियम, परंपराएँ और सर्वोत्तम अभ्यास

| नियम | कारण |
| - | - |
| प्रति इकाई एक मानक पहचानकर्ता चुनें और उसे कभी न बदलें | बदलाव से नई इकाई बनती है और इतिहास अलग-थलग हो जाता है |
| `vendor_data` मानों को इकाई प्रकार के अनुसार प्रीफ़िक्स दें (`user_...`, `biz_...`) | आपके अपने कोड में नेमस्पेस के बीच आकस्मिक टकराव रोकता है |
| `vendor_data` के केस-संवेदी मानों को स्थिर रखें | Didit केस को सामान्य (normalize) नहीं करता |
| `vendor_data` की लंबाई 128 वर्णों से कम रखें | डेटाबेस इंडेक्स में आराम से फ़िट होता है |
| कच्चा PII कभी उजागर न करें | `vendor_data` webhook, ऑडिट लॉग और API रिस्पॉन्स में दिखता है |

## अगले चरण

> [card] [उपयोगकर्ता अवलोकन](https://docs.didit.me/hi/entities/users/overview.md)
>
> उपयोगकर्ता इकाइयों और संचालन की विस्तृत जानकारी।

> [card] [व्यवसाय अवलोकन](https://docs.didit.me/hi/entities/businesses/overview.md)
>
> व्यवसाय इकाइयों और संचालन की विस्तृत जानकारी।

> [card] [सत्र बनाएँ](https://docs.didit.me/hi/sessions-api/create-session.md)
>
> किसी vendor\_data के लिए सत्यापन शुरू करें।

> [card] [लेन-देन बनाएँ](https://docs.didit.me/hi/management-api/transactions/create.md)
>
> किसी इकाई से जुड़ा लेन-देन सबमिट करें।


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