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

# उपयोगकर्ता और व्यवसाय webhook इवेंट

> Didit की उपयोगकर्ता और व्यवसाय entity के बदलावों के लिए रियल-टाइम webhooks: स्थिति परिवर्तन, प्रोफ़ाइल अपडेट, payload फ़ील्ड, हस्ताक्षर और पुनः प्रयास।



इकाई Webhooks प्रॉम्प्ट
        प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें



      
      

\<pre>

\````# Goal — subscribe to entity-level webhooks and apply changes to my database

Entity webhooks fire whenever a User or Business entity changes its status or its profile data. Use them to keep your local mirror of Didit entities in sync.

\## Entity-level event catalog

\| `webhook_type` | Trigger |
\|---|---|
\| `user.status.updated` | User entity status changed (`ACTIVE` / `FLAGGED` / `BLOCKED`). Payload includes `previous_status`. |
\| `user.data.updated` | User entity profile / counters / metadata changed. Includes `changed_fields` and a `changes` map of `{previous, current}`. |
\| `business.status.updated` | Business entity status changed. Payload includes `previous_status`. |
\| `business.data.updated` | Business entity profile or aggregates changed. Includes `changed_fields` and `changes`. |

\`activity.created` is accepted in `subscribed_events` and by the Try Webhook tester, but Didit does not deliver it for live traffic. Do not build on it.

Session-level events (`status.updated`, `data.updated`) and transaction events (`transaction.created`, `transaction.status.updated`) live alongside but are separate — see /integration/webhooks for the full catalog.

\## Register a destination

\```bash
curl -X POST https://verification.didit.me/v3/webhook/destinations/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"label": "Entity sync",
"url": "https://yourapp.com/webhooks/didit",
"webhook_version": "v3",
"subscribed_events": [
  "user.status.updated",
  "user.data.updated",
  "business.status.updated",
  "business.data.updated"
]
}'
\```

Persist the returned destination `secret_shared_key` — that's the HMAC signing key.

\## Payload shape

Entity payloads are flat: there is no `data` wrapper and no `event` key. Read `webhook_type`.

\```json
\{
"event_id": "7f3c2c1e-6a1d-4c36-9d8e-0d3b5f4e2a10",
"webhook_type": "user.status.updated",
"timestamp": 1776333600,
"created_at": 1776333594,
"application_id": "0c1d2e3f-4a5b-4c6d-8e7f-9a0b1c2d3e4f",
"environment": "live",
"vendor_user_id": "9c7d2a30-...",
"vendor_data": "user-42",
"status": "BLOCKED",
"previous_status": "ACTIVE"
}
\```

\`business.*` events use `vendor_business_id` instead of `vendor_user_id`.
\`user.data.updated` / `business.data.updated` payloads keep `status` and add `changed_fields` (array) and `changes` (`{field: {previous, current}}`). Use these to apply minimal diffs to your DB.

\## Verify the signature

Verify X-Signature-V2 (recommended): HMAC-SHA256 of the canonical JSON body with the destination `secret_shared_key`, then a constant-time compare, and reject an X-Timestamp older than 300 seconds. See /integration/webhooks for the signature headers and code samples. Respond `2xx` within **5 seconds**. On a 5xx, 404, timeout or connection failure Didit retries up to 2 times (about 1 minute, then about 4 minutes later); see /integration/webhooks#retry-policy.

\## Idempotency

Every delivery carries a unique `event_id`. De-dupe on it. Fallback compound key: `(application_id, webhook_type, vendor_data, timestamp)`.

\## Failure modes

\- Wrong `webhook_version` (e.g. v2) → singular fields and older event names; v3 is required for entity events plural-array contract.
\- Slow handler → retried; budget < 5s; do heavy work async.
\- Unknown event type → log and 200; new event types may be added.

\## Apply-decision pseudocode

\```ts
switch (event.webhook_type) {
case "user.status.updated":
await db.users.update({ vendor_data: event.vendor_data }, { status: event.status });
break;
case "user.data.updated":
for (const field of event.changed_fields) {
  await db.users.update({ vendor_data: event.vendor_data }, { [field]: event.changes[field].current });
}
break;
case "business.status.updated":
case "business.data.updated": /* same shape, businesses table, keyed by vendor_business_id */ break;
}
\```

\## Sources of truth

\- /integration/webhooks — destinations, signatures, retries, full event catalog
\- /management-api/webhook/create-destination — endpoint schema
\- /entities/users/operations — operations that emit user events
\- /entities/businesses/operations — operations that emit business events
\- /integration/integration-prompt — canonical end-to-end prompt````

\</pre>



      
      

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

हर बार जब उपयोगकर्ता या व्यवसाय इकाई की स्थिति या प्रोफ़ाइल डेटा बदलता है, तब एक webhook भेजा जाता है, ताकि आपका सिस्टम तुरंत प्रतिक्रिया दे सके।
इकाई webhooks का उपयोग प्रोफ़ाइल डेटा सिंक करने, अन्य सिस्टम में ब्लॉक लागू करने, या आगे के अनुपालन फ़्लो शुरू करने के लिए करें।## इवेंट कैटलॉग| इवेंट | ट्रिगर |
| - | - |
| `user.status.updated` | जब किसी उपयोगकर्ता इकाई की स्थिति बदलती है (`ACTIVE` ↔ `FLAGGED` ↔ `BLOCKED`) |
| `user.data.updated` | जब किसी उपयोगकर्ता इकाई के प्रोफ़ाइल फ़ील्ड बदलते हैं (नाम, जन्म तिथि, चेहरे की तस्वीर, कुल काउंटर, मेटाडेटा) |
| `business.status.updated` | जब किसी व्यवसाय इकाई की स्थिति बदलती है |
| `business.data.updated` | जब किसी व्यवसाय इकाई के प्रोफ़ाइल फ़ील्ड बदलते हैं (कानूनी नाम, पंजीकरण संख्या, देश, काउंटर) |> [!NOTE]
>
> `activity.created` को `subscribed_events` में स्वीकार किया जाता है और इसे **Try Webhook** टेस्टर में शामिल किया गया है, लेकिन Didit इसे फ़िलहाल लाइव ट्रैफ़िक के लिए डिलीवर नहीं करता।
> इसके आधार पर टाइमलाइन मिरर न बनाएँ।Didit सत्र, लेन-देन और व्यवसाय-सत्र इवेंट भी भेजता है, जिनमें इकाई के फ़ील्ड का संदर्भ होता है। देखें:- [KYB webhooks](https://docs.didit.me/hi/business-verification/webhooks.md): व्यवसाय सत्र इवेंट
- [लेन-देन निगरानी webhooks](https://docs.didit.me/hi/transaction-monitoring/webhooks.md): लेन-देन इवेंट
- [webhooks संदर्भ](https://docs.didit.me/hi/integration/webhooks.md): हस्ताक्षर सत्यापन, पुनः प्रयास और गंतव्य## पेलोड संरचनाएँइकाई webhooks फ़्लैट होते हैं: इनमें कोई `data` रैपर और कोई `event` कुंजी नहीं होती।
इवेंट को रूट करने के लिए `webhook_type` पढ़ें।```json theme={null}
{
  "event_id": "7f3c2c1e-6a1d-4c36-9d8e-0d3b5f4e2a10",
  "webhook_type": "user.status.updated",
  "timestamp": 1776333600,
  "created_at": 1776333594,
  "application_id": "0c1d2e3f-4a5b-4c6d-8e7f-9a0b1c2d3e4f",
  "environment": "live",
  "vendor_user_id": "9c7d2a30-2f98-4d4f-9d2d-1a7c4b1e5b6a",
  "vendor_data": "user-42",
  "status": "BLOCKED",
  "previous_status": "ACTIVE"
}
```| फ़ील्ड | विवरण |
| - | - |
| `vendor_user_id` / `vendor_business_id` | इकाई के लिए Didit का पहचानकर्ता। `business.*` इवेंट `vendor_business_id` का उपयोग करते हैं। |
| `vendor_data` | इकाई के लिए आपका पहचानकर्ता। |
| `status` | `ACTIVE`, `FLAGGED` या `BLOCKED`। |
| `previous_status` | केवल `*.status.updated` में। |
| `changed_fields` और `changes` | केवल `*.data.updated` में। |
| `created_at` | वह Unix सेकंड जब इकाई आख़िरी बार अपडेट हुई थी। |
| `timestamp` | वह Unix सेकंड जब Didit ने webhook भेजा। |### `user.status.updated` / `business.status.updated`यह स्थिति में हर बदलाव पर ट्रिगर होता है।
पेलोड में `status` और `previous_status` होते हैं।
इसमें यह नहीं बताया जाता कि स्थिति क्यों बदली: कारण जानने के लिए इकाई को कंसोल में खोलें।### `user.data.updated` / `business.data.updated`यह तब ट्रिगर होता है जब प्रोफ़ाइल फ़ील्ड बदलते हैं।
`changed_fields` में वे फ़ील्ड सूचीबद्ध होते हैं जो बदले, और `changes` में हर फ़ील्ड का `previous` और `current` मान होता है।```json theme={null}
{
  "event_id": "5d1e8f9a-0c32-4b6a-a7b6-2b9d6f0a3c41",
  "webhook_type": "user.data.updated",
  "timestamp": 1776333700,
  "created_at": 1776333694,
  "application_id": "0c1d2e3f-4a5b-4c6d-8e7f-9a0b1c2d3e4f",
  "environment": "live",
  "vendor_user_id": "9c7d2a30-2f98-4d4f-9d2d-1a7c4b1e5b6a",
  "vendor_data": "user-42",
  "status": "ACTIVE",
  "changed_fields": ["full_name", "session_count"],
  "changes": {
    "full_name": { "previous": null, "current": "John Doe" },
    "session_count": { "previous": 2, "current": 3 }
  }
}
````changed_fields` में ये फ़ील्ड आ सकते हैं:- उपयोगकर्ता: `vendor_data`, `display_name`, `full_name`, `date_of_birth`, `metadata`, `portrait_image`, `issuing_states`, `approved_emails`, `approved_phones`, `features`, `session_count`, `approved_count`, `declined_count`, `in_review_count`, `first_session_at`, `last_session_at`।
- व्यवसाय: `vendor_data`, `display_name`, `metadata`, `legal_name`, `registration_number`, `country_code`, `session_count`, `approved_count`, `declined_count`, `in_review_count`, `features`, `first_session_at`, `last_session_at`।केवल बदले हुए फ़ील्ड सिंक करने के लिए `changed_fields` और `changes` का उपयोग करें।## डिलीवरी, पुनः प्रयास और हस्ताक्षरसभी इकाई webhooks मानक डिलीवरी अनुबंध का पालन करते हैं:- **हस्ताक्षरित** HMAC-SHA256 से `X-Signature-V2` हेडर में (अनुशंसित), गंतव्य की `secret_shared_key` के साथ। `X-Signature` और अप्रचलित `X-Signature-Simple` भी भेजे जाते हैं, साथ में `X-Timestamp` भी।
- **पुनः प्रयास किया जाता है** अधिकतम 2 बार, लगभग 1 मिनट और लगभग 4 मिनट के बाद, जब आपका endpoint 5xx या 404 का उत्तर देता है, टाइमआउट होता है, या कनेक्ट नहीं हो पाता। पूरी नीति के लिए [webhooks संदर्भ](https://docs.didit.me/hi/integration/webhooks.md#पुनः-प्रयास-नीति) देखें।
- **आइडेम्पोटेंट** — हर webhook के payload में एक अनन्य `event_id` होता है; अपनी ओर से डुप्लिकेट हटाएँ।गंतव्य सेटअप और हस्ताक्षर सत्यापन के कोड उदाहरणों के लिए [webhooks संदर्भ](https://docs.didit.me/hi/integration/webhooks.md) देखें।## सब्सक्राइब करनाManagement API या Business Console के माध्यम से किसी webhook गंतव्य पर इकाई इवेंट सब्सक्राइब करें:```bash theme={null}
curl -X POST https://verification.didit.me/v3/webhook/destinations/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Entity sync",
    "url": "https://yourapp.com/webhooks/didit",
    "subscribed_events": [
      "user.status.updated",
      "user.data.updated",
      "business.status.updated",
      "business.data.updated"
    ]
  }'
```## अगले चरण> [card] [webhooks संदर्भ](https://docs.didit.me/hi/integration/webhooks.md)
>
> गंतव्य, हस्ताक्षर, पुनः प्रयास और सत्यापन।> [card] [गंतव्य बनाएँ](https://docs.didit.me/hi/management-api/webhook/create-destination.md)
>
> नया webhook endpoint पंजीकृत करें।> [card] [उपयोगकर्ता संचालन](https://docs.didit.me/hi/entities/users/operations.md)
>
> वे बदलाव जो उपयोगकर्ता webhooks ट्रिगर करते हैं।


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