इवेंट इनजेस्ट API - गैर-मौद्रिक निगरानी

लेन-देन ही पैसा है। इवेंट वे बाकी सभी चीज़ें हैं जो आपका प्लेटफ़ॉर्म जानता है: निकासी से पहले का लॉगिन, दो खातों के बीच चिप्स ले जाने वाला हैंड, वह बोनस जो दो बार दावा किया गया, और वह चार्जबैक जो एक हफ़्ते बाद आया। इवेंट हर श्रेणी के लिए एक ही एनवेलप का उपयोग करते हैं, डिज़ाइन से ही आइडेम्पोटेंट होते हैं, और उसी नियम इंजन द्वारा मूल्यांकित किए जाते हैं जो आपके लेन-देन को स्कोर करता है।

इवेंट इंजेस्ट करना opt-in है। इसे Transactions → Settings → Event monitoring में चालू करें। जब तक आप ऐसा नहीं करते, कुछ नहीं बदलता: आपके मौजूदा लेन-देन नियम केवल लेन-देन पर ही चलते रहते हैं, और कोई इवेंट नियम गलती से नहीं बनाया जा सकता, क्योंकि कोई नियम तब तक लेन-देन पर ही लागू होता है जब तक आप स्पष्ट रूप से इवेंट शामिल न करें।जब तक यह चालू नहीं होता, हर राइट लेन (POST /v3/events/, POST /v3/events/batch/, POST /v3/events/sdk-token/ और /v1/events/ डिवाइस लेन) 403 के साथ {"code": "event_monitoring_disabled"} लौटाती है, और कुछ भी संग्रहीत, समृद्ध या मूल्यांकित नहीं होता। रीड पर कोई असर नहीं पड़ता।

endpoints

endpoint	प्रमाणीकरण	इसके लिए उपयोग करें
`POST /v3/events/`	API कुंजी	आपके बैकएंड से एक इवेंट
`POST /v3/events/batch/`	API कुंजी	एक अनुरोध में 500 इवेंट तक
`POST /v3/events/sdk-token/`	API कुंजी	एक सीमित दायरे वाला डिवाइस क्रेडेंशियल बनाएं
`POST /v1/events/`	`X-Monitoring-Token`	डिवाइस SDK से एक इवेंट
`POST /v1/events/batch/`	`X-Monitoring-Token`	फ़्लश किया गया SDK बफ़र
`GET /v3/events/`	API कुंजी	इवेंट सूची देखें और फ़िल्टर करें
`GET /v3/events/{event_uuid}/`	API कुंजी	नियम के साक्ष्य सहित एक इवेंट
`GET /v3/events/subjects/{vendor_data}/`	API कुंजी	एक विषय की टाइमलाइन (नीचे `entity_type` देखें)
`GET /v3/events/enrichment-metrics/`	API कुंजी	IP एनरिचमेंट कैश की स्थिति

/v3/ लेन सर्वर लेन है और यह लेन-देन API के बाकी हिस्सों में इस्तेमाल होने वाले वही x-api-key प्रमाणीकरण का उपयोग करती है। /v1/events/ लेन डिवाइस लेन है, देखें SDK इवेंट सबमिशन।

एनवेलप

curl -X POST https://verification.didit.me/v3/events/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event_id": "login-2026-08-31-000001",
    "event_category": "auth",
    "action_type": "login",
    "occurred_at": "2026-08-31T20:40:31.123Z",
    "time_zone": "UTC",
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user_391"
    },
    "session": { "session_id": "web-session-abc", "sequence": 142 },
    "device_context": {
      "fingerprint": "didit-fp-v2:a8c1",
      "network_context": { "ip_address": "203.0.113.42" }
    },
    "payload": { "method": "password" }
  }'

{
  "event_uuid": "0f2b...",
  "event_id": "login-2026-08-31-000001",
  "status": "ACCEPTED",
  "score": 0,
  "rules_evaluated_count": 6,
  "rules_matched_count": 0,
  "correlation_pending": false,
  "retention_class": "standard",
  "expires_at": "2026-09-30T20:40:31.123Z",
  "idempotent_replay": false,
  "rule_matches": []
}

फ़ील्ड	आवश्यक	नोट्स
`event_id`	हाँ	आपका अपना पहचानकर्ता, हर एप्लिकेशन के लिए अद्वितीय। यही आइडेम्पोटेंसी कुंजी है।
`event_category`	हाँ	नीचे दी गई दस श्रेणियों में से एक।
`action_type`	हाँ	खुली स्ट्रिंग, अधिकतम 128 अक्षर।
`occurred_at`	हाँ	आपकी ओर से यह कब हुआ। अधिकतम 7 दिन पहले और 5 मिनट आगे तक।
`subject.vendor_data`	हाँ	आपकी उपयोगकर्ता आईडी। यह उसी उपयोगकर्ता पर हल होती है जिस पर कोई लेन-देन हल होता।
`subject.entity_type`	नहीं	`individual` (डिफ़ॉल्ट) या `company`।
`business.vendor_data`	नहीं	वह व्यवसाय जिससे इवेंट संबंधित है।
`session`	नहीं	`session_id`, `sequence`, `page_url`, `referrer`.
`device_context`	नहीं	`fingerprint`, `persistent_device_id`, `bot_score`, और `network_context.ip_address`.
`transaction_context`	नहीं	`amount`, `currency`, `direction`, `payment_reference_id`.
`payload`	नहीं	श्रेणी के डोमेन फ़ील्ड। 16 KB तक।
`custom_values`	नहीं	100 स्केलर कुंजियों तक, जिन्हें नियमों में `custom_values.<key>` के रूप में संबोधित किया जा सकता है।

श्रेणियाँ

दस प्रथम-श्रेणी की श्रेणियाँ, प्रत्येक में टाइप्ड सत्यापन और प्रबंधित नियम फ़ील्ड हैं।

श्रेणी	सामान्य कार्रवाइयाँ
`auth`	`signup`, `login`, `login_failed`, `logout`, `password_forgot`, `password_reset`, `mfa_reset`, `mfa_challenge`
`session`	`session_started`, `session_ended`, `page_view`, `sdk_loaded`, `device_seen`, `bot_signal_observed`, `sdk_heartbeat`
`gameplay`	`round_started`, `round_completed`, `bet_placed`, `bet_settled`, `cashout`, `limit_change`, `p2p_settlement`
`bonus`	`bonus_claimed`, `bonus_wagered`, `bonus_released`, `promotion_viewed`
`affiliate`	`affiliate_attributed`, `referral_clicked`, `campaign_joined`, `commission_event`
`payment`	`deposit_initiated`, `deposit_completed`, `withdrawal_requested`, `withdrawal_completed`, `withdrawal_address_changed`, `payment_instrument_seen`
`dispute`	`chargeback_opened`, `chargeback_won`, `chargeback_lost`, `refund_issued`, `payment_dispute_updated`
`security`	`login_attempt`, `login_succeeded`, `login_failed`, `password_changed`, `mfa_changed`, `credential_reset`, `country_changed`, `device_changed`, `account_locked`
`responsible_gambling`	`self_exclusion_checked`, `self_exclusion_match`, `re_registration_attempt`, `limit_breach_attempt`, `registry_status_changed`
`custom`	आप जो भी परिभाषित करें

auth व्यापक उत्पाद श्रेणी है; security जोखिम-ग्रेड का उपसमूह है, जिसका क्रमबद्ध जीवनचक्र होता है जिसे अकाउंट-टेकओवर नियम पढ़ते हैं।

आवश्यक payload कुंजियाँ

कुछ कार्रवाइयों को विशिष्ट कुंजियों के बिना सहसंबंधित नहीं किया जा सकता, इसलिए सत्यापन ऐसे इवेंट को अस्वीकार कर देता है, बजाय इसके कि ऐसे साक्ष्य संग्रहीत करे जिन्हें कोई जोड़ न सके।

कार्रवाई	आवश्यक
`gameplay.p2p_settlement`	`game_id`, `counterparty_vendor_data`, `stake_amount`, `net_result_amount`, `role`, और `hand_id` / `round_id` / `match_id` में से एक
`gameplay.bet_placed`, `gameplay.bet_settled`	`game_id`
`payment.deposit_*`, `payment.withdrawal_completed`, `payment.withdrawal_requested`, `payment.deposit_initiated`	`payment_reference_id`, `amount`, `currency`, `payment_method`, `status`
`payment.withdrawal_address_changed`	`withdrawal_address_hash`
`dispute.chargeback_*`	`payment_reference_id`, और `dispute_id` / `chargeback_id` में से एक
`security.*_changed`	`changed_field`; खाते या भुगतान-निकासी नियंत्रण में बदलाव के लिए `previous_reference_hash` या `new_reference_hash` भी आवश्यक हैं
`session.bot_signal_observed`	`telemetry_schema_version`, साथ में `bot_score` या कम से कम एक टेलीमेट्री मेट्रिक
`responsible_gambling.self_exclusion_match`	`registry_source`, `exclusion_status`, `identity_match_ref`

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

उदाहरण: P2P सेटलमेंट

{
  "event_id": "p2p-hand-8842-user-391",
  "event_category": "gameplay",
  "action_type": "p2p_settlement",
  "occurred_at": "2026-08-31T12:34:17.392Z",
  "subject": { "vendor_data": "user_391" },
  "payload": {
    "game_id": "poker_holdem",
    "table_id": "table_17",
    "hand_id": "hand_8842",
    "role": "winner",
    "counterparty_vendor_data": "user_812",
    "stake_amount": "250.00",
    "net_result_amount": "240.50",
    "effective_margin": "0.038",
    "operator_ledger_ref": "ledger_998123"
  }
}

उदाहरण: चार्जबैक

{
  "event_id": "chargeback-cb_921-opened",
  "event_category": "dispute",
  "action_type": "chargeback_opened",
  "occurred_at": "2026-08-31T09:22:05.000Z",
  "subject": { "vendor_data": "user_391" },
  "transaction_context": {
    "amount": "1000.00",
    "currency": "EUR",
    "payment_reference_id": "dep_735"
  },
  "payload": {
    "dispute_id": "disp_498",
    "chargeback_id": "cb_921",
    "reason_code": "fraudulent",
    "liability_shift": false
  }
}

डिस्प्यूट लाइफ़साइकिल केवल जोड़ने योग्य होते हैं: किसी सुधार के लिए पहले इवेंट को संपादित नहीं किया जाता, बल्कि एक नया dispute इवेंट भेजा जाता है।

आइडेम्पोटेंसी

event_id हर एप्लिकेशन में अनोखा होता है और यही पूरा आइडेम्पोटेंसी अनुबंध है।

वही event_id, वही सामग्री 200 लौटाता है, जिसमें "idempotent_replay": true और मूल रूप से संग्रहीत इवेंट होता है। जितनी बार चाहें, पुनः प्रयास करें।
वही event_id, अलग सामग्री 409 लौटाता है। आपने गलती से कोई आईडी दोबारा उपयोग की है।

बैच

POST /v3/events/batch/ 500 इवेंट तक स्वीकार करता है। बैच डिज़ाइन के अनुसार आंशिक रूप से सफल हो सकता है: एक खराब पेज व्यू के कारण उसके बगल वाला चार्जबैक कभी विफल नहीं होना चाहिए।

{
  "accepted_count": 2,
  "replayed_count": 0,
  "rejected_count": 1,
  "results": [
    { "index": 0, "outcome": "rejected", "errors": { "occurred_at": ["This field is required."] } },
    { "index": 1, "outcome": "accepted", "event_uuid": "…", "status": "ACCEPTED" },
    { "index": 2, "outcome": "accepted", "event_uuid": "…", "status": "IN_REVIEW" }
  ]
}

जब कोई इवेंट अस्वीकार होता है तो प्रतिक्रिया 207 Multi-Status होती है, और जब सब कुछ स्वीकार हो जाता है तो 201 Created।

स्थितियाँ

स्थिति	अर्थ
`ACCEPTED`	संग्रहीत। किसी नियम ने इसकी स्थिति नहीं बदली (ज़्यादातर इवेंट के लिए यही सामान्य उत्तर है)।
`APPROVED`	एक नियम चला और स्कोर आपकी समीक्षा थ्रेशोल्ड से नीचे रहा।
`IN_REVIEW`	किसी नियम ने इसे समीक्षा थ्रेशोल्ड से ऊपर धकेला, या स्थिति सीधे सेट की गई।
`DECLINED`	एक नियम ने इसे अस्वीकृत किया।

correlation_pending: true का अर्थ है कि एक क्रॉस-सब्जेक्ट नियम अभी चलना बाकी है; यह कुछ मिनटों में हल हो जाता है और इवेंट की स्थिति और स्कोर उसी स्थान पर अपडेट हो जाते हैं। देखें एसिंक्रोनस नियम।

प्रतिधारण

इवेंट लेन-देन से कहीं ज़्यादा मात्रा में आते हैं, इसलिए हर इवेंट आने पर एक प्रतिधारण श्रेणी में रखा जाता है।

श्रेणी	डिफ़ॉल्ट हॉट प्रतिधारण	यहाँ क्या आता है
`low_value`	14 दिन	पेज व्यू, हार्टबीट, डिवाइस देखे जाने के पिंग, बॉट टेलीमेट्री, प्रमोशन व्यू
`standard`	30 दिन	प्रमाणीकरण, सत्र, गेमप्ले, बोनस, एफिलिएट, कस्टम
`risk_relevant`	90 दिन	सुरक्षा और ज़िम्मेदार जुआ इवेंट, और कोई भी इवेंट जिससे किसी नियम ने मिलान किया
`monetary_or_compliance`	लेन-देन प्रतिधारण	भुगतान और विवाद इवेंट

तालिका से दो नियम निकलते हैं:

जो इवेंट किसी नियम से मेल खाता है वह साक्ष्य है, इसलिए वह अपने आप risk_relevant में बढ़ा दिया जाता है।
भुगतान और विवाद इवेंट लेन-देन प्रतिधारण ही रखते हैं। उन्हें इवेंट शेड्यूल पर कभी समाप्त नहीं किया जाता, और श्रेणी-विशिष्ट ओवरराइड उन्हें छोटा नहीं कर सकते।

तीनों समाप्त होने योग्य श्रेणियों को हर एप्लिकेशन के लिए Transactions → Settings → Event monitoring में ओवरराइड करें (हर एक के लिए 1-730 दिन)।

IP एनरिचमेंट

इवेंट में भी वही IP एनरिचमेंट होता है जो लेन-देन में होता है: देश, ASN, VPN/proxy और डेटा सेंटर फ़्लैग। एनरिचमेंट हर अनोखे IP पते के लिए हल होता है, कभी भी प्रति इवेंट नहीं। एक सत्र जो एक ही पते से 200 पेज व्यू भेजता है, उस पते को एक बार ही हल करता है। कम मूल्य वाली टेलीमेट्री इससे भी आगे जाती है: यह तभी एनरिचमेंट पढ़ती है जब किसी दूसरे इवेंट ने पहले ही उस पते को हल कर दिया हो। यह अपनी ओर से कभी लुकअप ट्रिगर नहीं करती। GET /v3/events/enrichment-metrics/ परिणाम रिपोर्ट करता है, और कंसोल इवेंट सूची के ऊपर वही संख्याएँ दिखाता है:

{
  "events_ingested": 128450,
  "enrichment_lookups": 41230,
  "enrichment_cache_hits": 40118,
  "enrichment_provider_calls": 1112,
  "enrichment_skipped_low_value": 74320,
  "unique_ips_seen": 1112,
  "cache_hit_rate": 0.973,
  "unique_ip_ratio": 0.0087,
  "provider_calls_per_1k_events": 8.65,
  "period_days": 30
}

इवेंट को फिर से पढ़ना

curl "https://verification.didit.me/v3/events/?event_category=payment&event_category=dispute&matched_only=true" \
  -H "x-api-key: YOUR_API_KEY"

फ़िल्टर: event_category, action_type, status, retention_class, subject_vendor_data, business_vendor_data, session_id, device_fingerprint, ip_address, game_id, round_id, affiliate_code, payment_reference_id, counterparty_vendor_data, matched_only, occurred_from, occurred_to, search. एक से अधिक मानों वाले फ़िल्टर पैरामीटर को दोहराते हैं (?status=A&status=B).

एक विषय की समयरेखा

curl "https://verification.didit.me/v3/events/subjects/acct_9931/?entity_type=company" \
  -H "x-api-key: YOUR_API_KEY"

vendor_data केवल किसी इकाई प्रकार के भीतर अद्वितीय होता है: एक ही आईडी किसी उपयोगकर्ता और किसी कंपनी दोनों को दर्शा सकती है, और Didit इन्हें दो अलग-अलग विषयों के रूप में हल करता है। entity_type बताता है कि आप किसे माँग रहे हैं: individual (डिफ़ॉल्ट) या company। कंपनी आईडी के लिए इसे छोड़ने पर केवल व्यक्ति की समयरेखा लौटाई जाती है, दोनों नहीं। ऊपर दिए गए वही फ़िल्टर लागू होते हैं। GET /v3/events/{event_uuid}/ में payload, डिवाइस संदर्भ, IP संवर्धन, विषय के कैश्ड जोखिम संकेत, और हर नियम का मिलान उसके साक्ष्य के साथ जुड़ जाता है। इसमें यह भी शामिल है कि मिलान किया गया हर फ़ील्ड सर्वर से प्राप्त था, SDK से प्राप्त था, या ग्राहक द्वारा प्रदान किया गया था। DELETE /v3/events/{event_uuid}/delete/ एक इवेंट को हटाता है। हटाए जाने के बाद यह किसी भी रीड अनुरोध में लौटाया जाना बंद हो जाता है, और हटाना अपरिवर्तनीय है।

आगे

इवेंट पर नियम

इवेंट डेटा पर वेलोसिटी, अनुपात, क्रम और सहसंबंध नियम।

SDK इवेंट सबमिशन

स्कोप्ड क्रेडेंशियल के साथ सीधे डिवाइस से इवेंट कैप्चर करें।

शुरुआत करें

सुविधाएँ

संदर्भ

कंसोल

इवेंट इनजेस्ट API - गैर-मौद्रिक निगरानी

endpoints

एनवेलप

श्रेणियाँ

आवश्यक payload कुंजियाँ

उदाहरण: P2P सेटलमेंट

उदाहरण: चार्जबैक

आइडेम्पोटेंसी

बैच

स्थितियाँ

प्रतिधारण

IP एनरिचमेंट

इवेंट को फिर से पढ़ना

एक विषय की समयरेखा

आगे

इवेंट पर नियम

SDK इवेंट सबमिशन

​endpoints

​एनवेलप

​श्रेणियाँ

​आवश्यक payload कुंजियाँ

​उदाहरण: P2P सेटलमेंट

​उदाहरण: चार्जबैक

​आइडेम्पोटेंसी

​बैच

​स्थितियाँ

​प्रतिधारण

​IP एनरिचमेंट

​इवेंट को फिर से पढ़ना

​एक विषय की समयरेखा

​आगे

इवेंट पर नियम

SDK इवेंट सबमिशन

endpoints

एनवेलप

श्रेणियाँ

आवश्यक payload कुंजियाँ

उदाहरण: P2P सेटलमेंट

उदाहरण: चार्जबैक

आइडेम्पोटेंसी

बैच

स्थितियाँ

प्रतिधारण

IP एनरिचमेंट

इवेंट को फिर से पढ़ना

एक विषय की समयरेखा

आगे