SDK इवेंट सबमिशन - क्लाइंट-साइड इवेंट कैप्चर

इवेंट धोखाधड़ी के लिए मायने रखने वाले ज़्यादातर डिवाइस पर होते हैं: लॉगिन, सत्र, गेमप्ले राउंड, और टाइमिंग टेलीमेट्री, जो किसी व्यक्ति को स्क्रिप्ट से अलग करती है। डिवाइस लेन इन इवेंट को ब्राउज़र में API कुंजी रखे बिना भेजती है। आपका बैकएंड एक अल्पावधि क्रेडेंशियल जारी करता है, जो एक उपयोगकर्ता तक सीमित होता है। ऐप उसी के साथ इवेंट पोस्ट करता है।

प्रवाह

मॉनिटरिंग क्रेडेंशियल जारी करें

आपका बैकएंड अपनी API कुंजी और उपयोगकर्ता के vendor_data के साथ POST /v3/events/sdk-token/ को कॉल करता है।

डिवाइस से सबमिट करें

ऐप X-Monitoring-Token हेडर के साथ POST /v1/events/ (या POST /v1/events/batch/) पर पोस्ट करता है।

नियम हमेशा की तरह चलते हैं

इवेंट को समृद्ध, रोल-अप और मूल्यांकित किया जाता है, ठीक उन्हीं नियमों द्वारा जिनके अनुसार सर्वर से सबमिट किए गए इवेंट का मूल्यांकन होता है।

क्रेडेंशियल जारी करना

क्रेडेंशियल जारी करने के लिए एप्लिकेशन पर इवेंट इंजेस्चन चालू होना ज़रूरी है। जब तक यह बंद है, यह endpoint 403 के साथ {"code": "event_monitoring_disabled"} लौटाता है, न कि ऐसा क्रेडेंशियल देता है जो कभी लिख ही न सके।

curl -X POST https://verification.didit.me/v3/events/sdk-token/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data": "user_391",
    "allowed_event_categories": ["auth", "session", "gameplay"],
    "ttl_seconds": 900,
    "max_uses": 1000,
    "bind_to_origin": "https://operator.example"
  }'

{
  "monitoring_token": "…",
  "expires_at": "2026-08-31T21:00:00Z",
  "allowed_event_categories": ["auth", "session", "gameplay"],
  "max_uses": 1000,
  "bind_to_origin": "https://operator.example"
}

फ़ील्ड	डिफ़ॉल्ट	नोट्स
`vendor_data`	आवश्यक	इस क्रेडेंशियल के साथ सबमिट किए गए हर इवेंट का विषय।
`entity_type`	`individual`	`individual` या `company`.
`allowed_event_categories`	सभी	सीमित करें कि लीक हुआ क्रेडेंशियल क्या लिख सकता है।
`ttl_seconds`	900	60 - 86400.
`max_uses`	1000	हर इवेंट पर एक उपयोग, प्रति अनुरोध नहीं।
`bind_to_origin`	कोई नहीं	सेट होने पर, ब्राउज़र का `Origin` बिल्कुल मेल खाना चाहिए।

सबमिट करना

curl -X POST https://verification.didit.me/v1/events/ \
  -H "X-Monitoring-Token: THE_MINTED_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "event_id": "session-abc-login-1",
    "event_category": "auth",
    "action_type": "login",
    "occurred_at": "2026-08-31T20:40:31.123Z",
    "session": { "session_id": "web-session-abc", "sequence": 1 },
    "device_context": { "fingerprint": "didit-fp-v2:a8c1" },
    "payload": { "method": "password" }
  }'

ध्यान दें कि payload में क्या नहीं होता: न API कुंजी, न विषय। ये दोनों सर्वर-साइड पर लागू होते हैं।

सर्वर क्या लागू करता है

विषय बाइंडिंग। क्रेडेंशियल जारी करते समय एक vendor_data से बंधा होता है। अनुरोध बॉडी में subject ब्लॉक ओवरराइट कर दिया जाता है, ताकि छेड़छाड़ किया गया क्लाइंट किसी दूसरे उपयोगकर्ता की टाइमलाइन में न लिख सके।
नेटवर्क संदर्भ। IP पता, user agent, accept-language और origin अनुरोध से निकाले जाते हैं। नियम मूल्यांकन के लिए ये सर्वर-व्युत्पन्न मान किसी भी क्लाइंट संकेत से ऊपर रहते हैं। नियम-साक्ष्य इस अंतर को फ़ील्ड स्रोत के रूप में दर्ज करता है।
श्रेणी का दायरा। session तक सीमित क्रेडेंशियल payment इवेंट सबमिट नहीं कर सकता। उसे 400 के साथ अस्वीकार किया जाता है।
उपयोग बजट। बैच हर इवेंट पर एक उपयोग खर्च करता है, इसलिए 500 इवेंट का बैच 10 उपयोग वाले क्रेडेंशियल को एक उपयोग बनाकर नहीं निकल सकता।
Origin बाइंडिंग। जब bind_to_origin सेट होता है, तो जिस अनुरोध का Origin मेल नहीं खाता, उसे मना किया जाता है। यह उस अनुरोध पर भी लागू होता है जिसमें कोई Origin नहीं है।

बैचिंग

curl -X POST https://verification.didit.me/v1/events/batch/ \
  -H "X-Monitoring-Token: THE_MINTED_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "events": [ { "…": "…" }, { "…": "…" } ] }'

हर फ़्लश में अधिकतम 500 इवेंट, और वही प्रति-आइटम परिणाम जो सर्वर बैच endpoint देता है। एक अच्छा डिफ़ॉल्ट फ़्लश है 25 इवेंट, 5 सेकंड, या पेज/ऐप के बैकग्राउंड में जाने पर।

बैकप्रेशर में क्या हटाएँ

अगर आपको इवेंट छोड़ने पड़ें, तो सस्ते इवेंट छोड़ें। ये ड्रॉप करना सुरक्षित है: session.page_view · session.sdk_heartbeat · session.sdk_loaded · session.device_seen · session.bot_signal_observed · bonus.promotion_viewed · affiliate.referral_clicked ये सुरक्षित रूप से ड्रॉप नहीं किए जा सकते, इन्हें पहले फ़्लश करें: हर security, payment, dispute और responsible_gambling इवेंट, साथ ही gameplay.bet_placed, gameplay.bet_settled और gameplay.p2p_settlement। सूची endpoints हर इवेंट के लिए यही वर्गीकरण is_droppable के रूप में लौटाते हैं, ताकि क्लाइंट किसी हार्डकोडेड कॉपी के बजाय उसी से संचालित हो सके।

हेडर संगतता

कैनोनिकल हेडर X-Monitoring-Token है। X-Transaction-Token एक अस्थायी उपनाम के रूप में स्वीकार किया जाता है, ताकि जो ऐप पहले से लेन-देन क्रेडेंशियल पथ रखता है, वह धीरे-धीरे माइग्रेट कर सके।

यह उपनाम अस्थायी है और इवेंट API के सामान्य उपलब्धता (GA) पर पहुँचने से पहले हटा दिया जाएगा। नए कोड में X-Monitoring-Token भेजें।

लेन चुनना

	डिवाइस लेन	सर्वर लेन
Endpoint	`POST /v1/events/`	`POST /v3/events/`
Auth	`X-Monitoring-Token`	`x-api-key`
विषय	क्रेडेंशियल से बंधा	payload में
सबसे उपयुक्त	लॉगिन, सत्र, गेमप्ले, टेलीमेट्री	भुगतान, विवाद, लेजर-व्युत्पन्न इवेंट, बैकफ़िल

दोनों एक जैसे इवेंट रिकॉर्ड बनाते हैं और एक जैसे नियम चलाते हैं। जब कोई अंतिम उपयोगकर्ता मौजूद न हो, तब हमेशा सर्वर लेन का उपयोग करें।

आगे

इवेंट इंजेस्चन

लिफ़ाफ़ा, श्रेणियाँ, प्रतिधारण और आइडेम्पोटेंसी।

इवेंट पर नियम

वेलोसिटी, रेशियो, सीक्वेंस और कोरिलेशन नियम।

शुरुआत करें

सुविधाएँ

संदर्भ

कंसोल

SDK इवेंट सबमिशन - क्लाइंट-साइड इवेंट कैप्चर

प्रवाह

क्रेडेंशियल जारी करना

सबमिट करना

सर्वर क्या लागू करता है

बैचिंग

बैकप्रेशर में क्या हटाएँ

हेडर संगतता

लेन चुनना

आगे

इवेंट इंजेस्चन

इवेंट पर नियम

​प्रवाह

​क्रेडेंशियल जारी करना

​सबमिट करना

​सर्वर क्या लागू करता है

​बैचिंग

​बैकप्रेशर में क्या हटाएँ

​हेडर संगतता

​लेन चुनना

​आगे

इवेंट इंजेस्चन

इवेंट पर नियम

प्रवाह

क्रेडेंशियल जारी करना

सबमिट करना

सर्वर क्या लागू करता है

बैचिंग

बैकप्रेशर में क्या हटाएँ

हेडर संगतता

लेन चुनना

आगे