आपका डेटा, वहीं जहाँ आप फ़ैसला लेते हैं
हर आइडेंटिफ़िकेशन आपके सिस्टम तक दो तरीक़ों से पहुँच सकता है: घटते ही आपके सर्वर पर भेजा हुआ, या ठीक उस सेकंड आपके द्वारा माँगा हुआ जब आप फ़ैसला लेते हैं। दोनों चैनल वही आँकड़े लाते हैं — और यह वादे से नहीं, एक टेस्ट से बँधा है।
पुश या पुल
वेबहुक इवेंट होते ही आपको भेज देते हैं। Data API आपको तब पूछने देता है जब आपको जवाब चाहिए। ज़्यादातर टीमें दोनों चलाती हैं: दर्ज करने और प्रतिक्रिया देने के लिए वेबहुक, और इनलाइन जाँच के लिए Data API।
वेबहुक — पुश, रियल टाइम में
कुछ भी होते ही हम आपके एंडपॉइंट पर साइन किया हुआ JSON इवेंट POST करते हैं: कोई विज़िटर पहचाना गया, अकाउंट टेकओवर फ़्लैग हुआ, कोई बॉट हमला शुरू हुआ। न पोल करना है, न कोई शेड्यूल बनाना है।
इसके लिए सबसे अच्छा: हर विज़िट दर्ज करना, हमलों पर प्रतिक्रिया देना, अपने वेयरहाउस या SIEM को डेटा देना।
p50 डिलीवरी लेटेंसी 44–140 ms, इवेंट से आपके एंडपॉइंट तक।
Data API — पुल, माँगने पर
एक निजी सर्वर-टू-सर्वर API। आपका बैकएंड सीक्रेट की से प्रमाणित होता है और ठीक उसी सेकंड पढ़ता है जब वह फ़ैसला लेता है कि किसी विज़िटर के बारे में हम क्या जानते हैं — आमतौर पर लॉगिन या चेकआउट हैंडलर के भीतर।
इसके लिए सबसे अच्छा: कार्ड चार्ज करने, साइनअप मंज़ूर करने या अकाउंट अनलॉक करने से पहले की इनलाइन जाँच।
Pro प्लान से उपलब्ध।
चार इवेंट प्रकार, एक ही लिफ़ाफ़ा
हर डिलीवरी उसी लिफ़ाफ़े में आती है, इवेंट प्रकार बॉडी में भी होता है और X-Tracio-Event-Type हेडर में भी — इसलिए एक ही हैंडलर चारों को रूट कर सकता है।
विज़िटर पहचाना गया
मुख्य इवेंट: एक विज़िट स्कोर हुई। इसमें विज़िटर ID, ब्राउज़र और OS, जियो और नेटवर्क, बॉट वर्डिक्ट और जोखिम-निर्णय आते हैं। यह चरणों में भेजा जाता है — पेज लोड पर प्राथमिक इवेंट, फिर देर से आने वाला या सुधार वाला चरण जब धीमे सबूत वर्डिक्ट बदल देते हैं। चरणों को requestId से जोड़िए।
identificationअकाउंट टेकओवर
किसी विज़िट पर अकाउंट-टेकओवर डिटेक्टर चला: किसी ज्ञात अकाउंट के पीछे का डिवाइस अब वह डिवाइस नहीं लगता जिसका वह अकाउंट है। यह आइडेंटिफ़िकेशन बॉडी में छिपने के बजाय अपने अलग इवेंट के रूप में आता है, और साथ में अकाउंट का संदर्भ भी।
account_takeoverबॉट हमला
आपके वर्कस्पेस पर स्वचालित ट्रैफ़िक का उछाल। इसके पीछे कोई विज़िट नहीं होती — यह वर्कस्पेस-स्तर की चेतावनी है, इसलिए विज़िट ब्लॉक शून्य स्कोर वाले खाली खोलों की तरह आने के बजाय बॉडी से बस ग़ैरहाज़िर रहते हैं।
attack_detectedरेप्युटेशन में बदलाव
कोई प्रोफ़ाइल एक रेप्युटेशन बैंड से दूसरे में गई। लिफ़ाफ़ा वही है जो हमले की चेतावनी का — प्रोफ़ाइल-स्तर का इवेंट, जिसके साथ कोई विज़िट नहीं होती, और जो नया तथा पिछला दोनों बैंड लेकर आता है।
reputation_changedएक डिलीवरी, छाँटकर
यह आधार बॉडी है। Pro इसमें विज़िट वेलोसिटी जोड़ता है; Business इसी आकार में वर्डिक्ट रीज़न कोड, व्यवहार सिग्नल, Guidance और क्रॉस-ब्राउज़र डिवाइस डेटा जोड़ता है — नए ब्लॉक आते हैं, मौजूदा पथ कभी नहीं हिलते।
{ "version": 2, "event": "identification", "eventId": "req_8f21c4:primary", "requestId": "req_8f21c4", "phase": "primary", "visitorId": "3f9a1b2c4d5e6f70", "timestamp": "2026-07-30T12:00:00Z", "geo": { "country": "DE", "city": "Berlin", "timezone": "Europe/Berlin" }, "network": { "vpn": true, "proxy": false, "tor": false, "datacenter": false }, "bot": { "result": "human", "score": 12 }, "identification": { "confidence": 0.97, "incognito": false }, "decision": { "action": "suspicious", "riskScore": 65.9 }}हर अनुरोध दो सिग्नेचर लेकर आता है
X-Tracio-Signature सिग्नेचर टाइमस्टैम्प और कच्ची रिक्वेस्ट बॉडी को जोड़कर बनाया गया HMAC-SHA256 है, जिसकी की आपका वेबहुक सीक्रेट है — यह साबित करता है कि भेजने वाला वह सीक्रेट जानता है जो आप दोनों के पास है। X-Tracio-Signature-Ed25519 प्लेटफ़ॉर्म सिग्नेचर है: उसे आप एक well-known एंडपॉइंट से लिए गए पब्लिक की से जाँचते हैं, इसलिए आपकी तरफ़ कुछ भी गुप्त रखने की ज़रूरत नहीं। टाइमस्टैम्प साइन की गई सामग्री का हिस्सा है, और यही पुराने कैप्चर को दोबारा भेजने के काम का नहीं रहने देता।
कच्चे रिक्वेस्ट बाइट्स के आधार पर जाँचिए — दोबारा सीरियलाइज़ किया गया JSON बाइट्स बदल देता है और सिग्नेचर मेल नहीं खाएगा। रीट्राई वही X-Tracio-Event-Id लेकर आते हैं, इसलिए उसी पर डीडुप्लिकेट कीजिए।
हर डिलीवरी के हेडर
X-Tracio-Signature: t=1753444800,v1=5257a869e7ecebed...X-Tracio-Signature-Ed25519: t=1753444800,kid=k1,v1=0Zx0M0n8...X-Tracio-Event-Type: identificationX-Tracio-Event-Id: req_8f21c4:primaryX-Tracio-Delivery-Attempt: 1X-Tracio-Payload-Version: 2इस तरह बनाया गया कि इवेंट खोएँ नहीं
डिलीवरी एक अलग फ़्लीट पर चलती है, और सत्य का स्रोत कतार है, किसी प्रोसेस की मेमोरी नहीं। यही at-least-once को असली बनाता है: अगर कोई डिलीवरी नोड बीच रास्ते मर जाए, इवेंट कतार में बना रहता है और दूसरा नोड उसे उठा लेता है।
ऐसे रीट्राई जो असली आउटेज पर फ़िट बैठते हैं
5 से., 30 से., 2 मिनट, 10 मिनट, 30 मिनट, 2 घंटे, 6 घंटे। पहले रीट्राई एक मिनट के भीतर आ जाते हैं, इसलिए आपकी सेवा के छोटे रीस्टार्ट की कोई क़ीमत नहीं चुकानी पड़ती। हर ठहराव सूचीबद्ध मान के आधे और पूरे के बीच से बेतरतीब चुना जाता है, ताकि आउटेज के बाद रीट्राई एक ही झोंके में वापस न आएँ।
ऑटो-डिसेबल जो बेवजह नहीं चलता
वेबहुक तभी बंद होता है जब विफलताएँ थ्रेशोल्ड तक भी पहुँचें और कम से कम 15 लगातार मिनट तक चलती भी रहें — रीस्टार्ट के दौरान कतार में जमा डिलीवरी का एक झोंका इंटीग्रेशन नहीं मार देगा। 410 Gone तुरंत बंद कर देता है। डैशबोर्ड कारण, रिस्पॉन्स कोड और फिर से चालू करने का बटन दिखाता है।
बिना अंतराल के सीक्रेट रोटेशन
रोटेशन के बाद दोनों सीक्रेट 24 घंटे तक वैध रहते हैं और हेडर दोनों सिग्नेचर लेकर आता है, इसलिए किसी एक का मेल भी काफ़ी है। आप कटओवर से दौड़ लगाने के बजाय इसी विंडो के भीतर अपना कॉन्फ़िगरेशन बदल लेते हैं; जब विंडो जल्दी ख़त्म करनी हो तो “Revoke now” उसे छोटा कर देता है।
एक डिलीवरी लॉग जिसे आप पढ़ सकते हैं
हर प्रयास — रिस्पॉन्स कोड, अवधि, एरर टेक्स्ट — डैशबोर्ड में हर वेबहुक के लिए दिखता है, और उसी के बगल में एक टेस्ट एक्शन है जो आपके एंडपॉइंट पर साइन किया हुआ नमूना पेलोड भेजता है, ताकि लाइव जाने से पहले आप अपना वेरिफ़ायर जाँच सकें।
उसी क्षण पूछिए जब आप फ़ैसला लेते हैं
api.tracio.ai पर एक निजी सर्वर-टू-सर्वर API। आपका बैकएंड सीक्रेट की से प्रमाणित होता है और अपना ही डेटा पढ़ता है। यह जानबूझकर कोई CORS हेडर नहीं भेजता: सीक्रेट की आपके पूरे वर्कस्पेस तक पहुँच देती है और उसे कभी ब्राउज़र तक नहीं पहुँचना चाहिए। Pro प्लान से उपलब्ध।
| मेथड | पथ | क्या लौटाता है |
|---|---|---|
| GET | /v1/visitors/{visitorId} | विज़िटर सारांश: पहली और आख़िरी बार कब देखा गया, विज़िट की संख्या, अलग-अलग IP और देश, ब्राउज़र और डिवाइस, जोखिम का इतिहास — और साथ में उनका नवीनतम सेशन। |
| GET | /v1/visitors/{visitorId}/sessions | कर्सर पेजिनेशन वाली सेशन सूची, तारीख़ की सीमा, बॉट नतीजे और न्यूनतम जोखिम स्कोर के फ़िल्टर के साथ। |
| GET | /v1/visitors/{visitorId}/sessions/latest | नवीनतम सेशन, एक ही ऑब्जेक्ट के रूप में, बिना किसी लिस्ट लिफ़ाफ़े के। |
| GET | /v1/sessions/{requestId} | कोई एक विशिष्ट सेशन। उसके साथ visitorId भी भेजिए और खोज आपके पूरे इतिहास के बजाय विज़िटर इंडेक्स से होकर जाएगी। |
| GET | /v1/visitors/{visitorId}/velocity | एक विंडो में गतिविधि — 1h, 24h या 7d: कितनी विज़िट, कितने IP से, कितने देशों से, कितने अकाउंट के अंतर्गत। |
चेकआउट पर विज़िटर की जाँच
आम कॉल: आपके पेमेंट हैंडलर के भीतर, कार्ड ऑथराइज़ करने से पहले। एक अनुरोध, एक जवाब, और meta ब्लॉक बताता है कि आपको असल में कितनी बड़ी विंडो मिली — अगर आप छह महीने माँगते हैं और आपका प्लान 30 दिन रखता है, तो वह 30 दिन लौटाता है और यह बता भी देता है।
अनुरोध
# Inside your checkout handler, before you authorize the cardcurl -s -H "Authorization: Bearer $TRACIO_SECRET_KEY" \ "https://api.tracio.ai/v1/visitors/3f9a1b2c/velocity?window=24h"जवाब
{ "window": "24h", "events": 128, "uniqueIps": 4, "uniqueCountries": 2, "uniqueAccounts": 1, "meta": { "plan": "business", "retentionDays": 30 }}हर जगह वही आँकड़े
जो विज़िट आपके डैशबोर्ड में 65.9 स्कोर करती है, वह Data API में भी 65.9 और वेबहुक बॉडी में भी 65.9 स्कोर करती है। दो स्वतंत्र रेंडरिंग एक-दूसरे से खिसक सकती थीं — स्केल इसका सबसे जाना-पहचाना तरीक़ा है, एक चैनल आपको 0.93 देता है जहाँ दूसरा 93 कहता है — इसलिए एक पैरिटी टेस्ट एक विज़िट बनाता है, उसे दोनों चैनलों से रेंडर करता है और कच्चे JSON पर सार्वजनिक फ़ील्ड की तुलना करता है। यह सहमति दावे से नहीं, जाँच से लागू होती है।
सिर्फ़ आँकड़े नहीं, सलाह
स्कोर बताते हैं कि हमने क्या देखा। Guidance बताता है कि उसका क्या करना है — उन चार फ़ैसलों के लिए जिनमें असल में पैसा लगता है, वर्शन वाले नियमों से गणना करके, और साथ में तर्क भी।
पेमेंट लें?
कार्ड ऑथराइज़ करने से पहले जोखिम, फ्रॉड रेप्युटेशन और बॉट वर्डिक्ट को तौलता है।
साइनअप स्वीकार करें?
फेंकने लायक़ अकाउंट को बनने से पहले पकड़ता है — यहाँ मल्टी-अकाउंटिंग और रेप्युटेशन सबसे भारी पड़ते हैं।
अंदर आने दें?
जब विज़िट पर अकाउंट-टेकओवर डिटेक्टर चला हो, तो अपने आप सख़्त हो जाता है।
कन्वर्ज़न गिनें?
असली रेफ़रल को खुद के रेफ़रल या प्रोत्साहित बॉट से अलग करता है।
चार शब्दों की शब्दावली
हर परिदृश्य को चार में से एक जवाब मिलता है, और उसके साथ वह आधार भी जिस पर वह जारी हुआ — एक तय शब्दावली से निर्णायक अक्ष: बॉट, जोखिम, फ्रॉड रेप्युटेशन, व्यवहार, मल्टी-अकाउंटिंग, अकाउंट टेकओवर, नेटवर्क, एफ़िलिएट पैटर्न। आप हमेशा जानते हैं कि किस अक्ष ने सलाह हिलाई, और इसके लिए सिग्नल नाम, भार या थ्रेशोल्ड देखने की ज़रूरत कभी नहीं पड़ती।
एक गणना, तीन चैनल
वही Guidance ब्लॉक वेबहुक के साथ चलता है, Data API में जवाब देता है और डैशबोर्ड में विज़िटर कार्ड पर दिखता है — एक ही नियम-सेट, एक ही नतीजा, आपकी तरफ़ कुछ भी मिलाने की ज़रूरत नहीं। कुल के बजाय अपने परिदृश्य की सलाह पढ़िए: कुल तो बस चारों में से सबसे सख़्त है, डैशबोर्ड के लिए एक सारांश, पेमेंट का फ़ैसला नहीं। नियम का वर्शन पेलोड में आता है, इसलिए नियमों का बदलना वह चीज़ है जो आपको दिखती है, न कि सलाह के खिसकने से जिसका अंदाज़ा लगाना पड़े।
"guidance": { "version": 1, "overall": "review", "payment": "review", "registration": "challenge", "login": "allow", "affiliate": "allow", "basis": ["risk", "fraud_reputation"]}फ्रंट एंड पर पाँच SDK, बैक एंड पर दो चैनल
ब्राउज़र की तरफ़ पाँच SDK आते हैं — वनीला JavaScript, React, Vue 3, Angular और Svelte 5। सर्वर-साइड SDK नहीं हैं, और यह जानबूझकर है: आपका बैकएंड साइन किए गए वेबहुक और Data API के ज़रिए सादे HTTP पर जुड़ता है। सिग्नेचर जाँच हमारे प्रकाशित रेफ़रेंस वेक्टर के मुक़ाबले एक दर्जन लाइन की बात है, और आपकी सर्वर डिपेंडेंसी में लगातार अपग्रेड करते रहने लायक़ कुछ अतिरिक्त बचता ही नहीं।
अक्सर पूछे जाने वाले प्रश्न
एक दोपहर में जोड़ लीजिए
डैशबोर्ड में वेबहुक बनाइए, उसे अपने एंडपॉइंट पर लगाइए और Test दबाइए। हमारे रेफ़रेंस वेक्टर के मुक़ाबले सिग्नेचर जाँच लीजिए — मुश्किल हिस्सा पीछे छूट गया।