ข้ามไปยังเนื้อหา
การส่งข้อมูล

ข้อมูลของคุณ ในจุดที่คุณตัดสินใจ

ทุกการระบุตัวตนเดินทางถึงระบบของคุณได้สองทาง คือถูกส่งไปยังเซิร์ฟเวอร์ของคุณทันทีที่มันเกิดขึ้น หรือคุณดึงมาเองในวินาทีที่คุณตัดสินใจ ทั้งสองช่องทางให้ตัวเลขชุดเดียวกัน และส่วนนั้นถูกล็อกไว้ด้วยการทดสอบ ไม่ใช่ด้วยคำสัญญา

เริ่มทดลองใช้ฟรีจองการสาธิต
สองช่องทาง

push หรือ pull

Webhook ส่งเหตุการณ์มาให้คุณตามที่มันเกิดขึ้น ส่วน Data API ให้คุณถามได้ในจังหวะที่คุณต้องการคำตอบ ทีมส่วนใหญ่ใช้ทั้งสองอย่าง คือ Webhook สำหรับบันทึกและตอบสนอง และ Data API สำหรับตรวจสอบแบบอินไลน์

Webhook — push แบบเรียลไทม์

เรา POST อีเวนต์ JSON ที่มีลายเซ็นไปยัง endpoint ของคุณทันทีที่มีอะไรเกิดขึ้น ไม่ว่าจะเป็นผู้เข้าชมถูกระบุตัวตน การยึดบัญชีถูกติดธง หรือการโจมตีด้วยบอตเริ่มต้นขึ้น ไม่ต้อง polling ไม่ต้องตั้งเวลา

เหมาะที่สุดสำหรับ การบันทึกทุกการเข้าชม การตอบสนองต่อการโจมตี การป้อนข้อมูลเข้าคลังข้อมูลหรือ SIEM ของคุณ

ความหน่วงในการส่งที่ p50 อยู่ที่ 44–140 ms จากอีเวนต์ถึง endpoint ของคุณ

Data API — pull ตามที่ร้องขอ

API ส่วนตัวแบบเซิร์ฟเวอร์ถึงเซิร์ฟเวอร์ แบ็กเอนด์ของคุณยืนยันตัวตนด้วย secret key และอ่านสิ่งที่เรารู้เกี่ยวกับผู้เข้าชมคนหนึ่งได้ตรงวินาทีที่มันตัดสินใจ โดยทั่วไปคืออยู่ภายใน handler ของการล็อกอินหรือการชำระเงิน

เหมาะที่สุดสำหรับ การตรวจสอบแบบอินไลน์ก่อนที่คุณจะตัดบัตร อนุมัติการสมัคร หรือปลดล็อกบัญชี

ใช้ได้ตั้งแต่แผน Pro

Webhook

สี่ประเภทอีเวนต์ ซองเดียวกัน

ทุกการส่งมาในซองเดียวกัน โดยมีประเภทอีเวนต์อยู่ทั้งใน body และในเฮดเดอร์ X-Tracio-Event-Type ดังนั้น handler ตัวเดียวจึงจัดเส้นทางได้ครบทั้งสี่

ผู้เข้าชมถูกระบุตัวตน

อีเวนต์หลัก คือมีการเข้าชมหนึ่งครั้งถูกให้คะแนน มันพา ID ผู้เข้าชม เบราว์เซอร์และระบบปฏิบัติการ ตำแหน่งและเครือข่าย คำตัดสินเรื่องบอตและการตัดสินใจด้านความเสี่ยงมาด้วย ระบบส่งเป็นเฟส คืออีเวนต์หลักตอนโหลดหน้า แล้วตามด้วยเฟสล่าช้าหรือเฟสแก้ไขเมื่อหลักฐานที่มาช้ากว่าทำให้คำตัดสินเปลี่ยน จับคู่เฟสต่าง ๆ ด้วย requestId

identification

การยึดบัญชี

ตัวตรวจจับการยึดบัญชีทำงานบนการเข้าชมหนึ่ง คืออุปกรณ์ที่อยู่หลังบัญชีที่รู้จักไม่เหมือนอุปกรณ์ของเจ้าของบัญชีอีกต่อไป มันมาเป็นอีเวนต์ของตัวเองพร้อมบริบทของบัญชีแนบมาด้วย แทนที่จะซ่อนอยู่ภายใน body ของอีเวนต์ระบุตัวตน

account_takeover

การโจมตีด้วยบอต

ทราฟฟิกอัตโนมัติพุ่งขึ้นในเวิร์กสเปซของคุณ อีเวนต์นี้ไม่มีการเข้าชมอยู่เบื้องหลัง มันเป็นการแจ้งเตือนระดับเวิร์กสเปซ บล็อกข้อมูลการเข้าชมจึงหายไปจาก body เฉย ๆ แทนที่จะมาเป็นเปลือกเปล่าที่มีคะแนนเป็นศูนย์

attack_detected

ชื่อเสียงเปลี่ยนแปลง

โปรไฟล์หนึ่งย้ายระหว่างช่วงชั้นชื่อเสียง ใช้ซองเดียวกับการแจ้งเตือนการโจมตี คือเป็นอีเวนต์ระดับโปรไฟล์ที่ไม่มีการเข้าชมแนบมา และพาช่วงชั้นใหม่กับช่วงชั้นก่อนหน้ามาด้วย

reputation_changed

ตัวอย่างการส่งหนึ่งครั้ง แบบตัดทอน

นี่คือ body พื้นฐาน แผน Pro เพิ่ม visit velocity เข้ามา ส่วน Business เพิ่มรหัสเหตุผลของคำตัดสิน สัญญาณพฤติกรรม Guidance และข้อมูลอุปกรณ์ข้ามเบราว์เซอร์ลงในรูปทรงเดิมเป๊ะ ๆ คือมีบล็อกใหม่โผล่ขึ้นมา แต่เส้นทางเดิมไม่เคยขยับ

JSON
{
  "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 ที่คำนวณจากไทม์สแตมป์ของลายเซ็นต่อกับ body ดิบของคำขอ โดยใช้ webhook secret ของคุณเป็นกุญแจ มันพิสูจน์ว่าผู้ส่งรู้ secret ที่ทั้งสองฝ่ายถือร่วมกัน ส่วน X-Tracio-Signature-Ed25519 คือลายเซ็นระดับแพลตฟอร์ม คุณตรวจสอบมันด้วย public key ที่ดึงจาก endpoint แบบ well-known ฝั่งคุณจึงไม่มีอะไรเป็นความลับให้ต้องเก็บ ไทม์สแตมป์เป็นส่วนหนึ่งของเนื้อหาที่ถูกเซ็น และนั่นคือสิ่งที่ทำให้การดักจับเก่า ๆ นำมาเล่นซ้ำไม่ได้

ตรวจสอบกับไบต์ดิบของคำขอ เพราะ JSON ที่ถูก serialize ใหม่จะเปลี่ยนไบต์และลายเซ็นจะไม่ตรง การส่งซ้ำจะพา X-Tracio-Event-Id ตัวเดิมมาด้วย จึงควรตัดข้อมูลซ้ำโดยอิงค่านั้น

เฮดเดอร์ในทุกการส่ง

Text
X-Tracio-Signature:         t=1753444800,v1=5257a869e7ecebed...
X-Tracio-Signature-Ed25519: t=1753444800,kid=k1,v1=0Zx0M0n8...
X-Tracio-Event-Type:        identification
X-Tracio-Event-Id:          req_8f21c4:primary
X-Tracio-Delivery-Attempt:  1
X-Tracio-Payload-Version:   2
ความน่าเชื่อถือ

สร้างมาเพื่อไม่ให้อีเวนต์หาย

การส่งทำงานบนฟลีตเฉพาะของมันเอง และแหล่งความจริงคือคิว ไม่ใช่หน่วยความจำของโปรเซส นั่นคือสิ่งที่ทำให้ at-least-once เป็นจริง ถ้าโหนดส่งตายกลางทาง อีเวนต์ยังอยู่ในคิวและอีกโหนดหนึ่งจะหยิบไปทำต่อ

อีเวนต์ต่อวินาทีผ่าน Webhook ตัวเดียว เพิ่มขึ้นจากราว 50 ก่อนการรื้อระบบใหม่เมื่อเดือนกรกฎาคม
44–140 msความหน่วงในการส่งที่ p50 จากอีเวนต์ถึง endpoint ของคุณ
ครั้งของการพยายามส่งบนบันไดที่ถ่างออกเรื่อย ๆ กระจายยาวได้ถึง 8.7 ชั่วโมง
จาก 90,000 อีเวนต์ที่ส่งสำเร็จในการซ้อมที่จงใจฆ่าโหนดส่งขณะรับโหลด

การลองใหม่ที่เข้ากับเหตุขัดข้องจริง

5 วินาที 30 วินาที 2 นาที 10 นาที 30 นาที 2 ชั่วโมง 6 ชั่วโมง การลองใหม่ครั้งแรก ๆ ลงภายในหนึ่งนาที การรีสตาร์ตสั้น ๆ ของบริการคุณจึงไม่ทำให้เสียอะไรเลย แต่ละช่วงพักถูกสุ่มเลือกระหว่างครึ่งหนึ่งของค่าที่ระบุกับค่าเต็ม การลองใหม่จึงไม่ย้อนกลับมาเป็นชุดเดียวพร้อมกันหลังเหตุขัดข้อง

การปิดอัตโนมัติที่ไม่ลั่นผิดจังหวะ

Webhook จะถูกปิดก็ต่อเมื่อความล้มเหลวทั้งถึงเกณฑ์และดำเนินต่อเนื่องมาแล้วอย่างน้อย 15 นาทีติดกัน การส่งที่ค้างคิวพรวดเดียวระหว่างรีสตาร์ตจึงไม่ฆ่าการเชื่อมต่อทิ้ง ส่วน 410 Gone จะปิดทันที แดชบอร์ดแสดงเหตุผล รหัสตอบกลับ และปุ่มเปิดใช้งานใหม่

หมุน secret โดยไม่มีช่องว่าง

หลังการหมุน secret ทั้งสองตัวยังใช้ได้ 24 ชั่วโมง และเฮดเดอร์พาลายเซ็นทั้งสองมาด้วย ตรงตัวใดตัวหนึ่งก็เพียงพอ คุณจึงอัปเดตคอนฟิกภายในหน้าต่างเวลานั้นแทนที่จะต้องแข่งกับการตัดสวิตช์ และปุ่ม “Revoke now” จะตัดหน้าต่างให้สั้นลงเมื่อคุณต้องการให้มันหายไปเดี๋ยวนี้

บันทึกการส่งที่คุณอ่านได้

ทุกครั้งที่พยายามส่ง ทั้งรหัสตอบกลับ ระยะเวลา และข้อความข้อผิดพลาด จะเห็นได้รายตัว Webhook ในแดชบอร์ด ข้าง ๆ กันมีปุ่มทดสอบที่ส่ง payload ตัวอย่างพร้อมลายเซ็นไปยัง endpoint ของคุณ เพื่อให้คุณยืนยันตัวตรวจสอบลายเซ็นของตัวเองได้ก่อนขึ้นใช้งานจริง

Data API

ถามในจังหวะที่คุณตัดสินใจ

API ส่วนตัวแบบเซิร์ฟเวอร์ถึงเซิร์ฟเวอร์ที่ api.tracio.ai แบ็กเอนด์ของคุณยืนยันตัวตนด้วย secret key และอ่านข้อมูลของตัวเอง มันจงใจไม่ส่งเฮดเดอร์ CORS ใด ๆ เพราะ secret key ให้สิทธิ์เข้าถึงทุกอย่างในเวิร์กสเปซของคุณ และต้องไม่หลุดไปถึงเบราว์เซอร์เด็ดขาด ใช้ได้ตั้งแต่แผน 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 จากกี่ประเทศ ภายใต้กี่บัญชี

ตรวจสอบผู้เข้าชมตอนชำระเงิน

การเรียกใช้แบบทั่วไป คืออยู่ภายใน handler การชำระเงินของคุณ ก่อนที่คุณจะอนุมัติบัตร หนึ่งคำขอ หนึ่งคำตอบ และบล็อก meta จะรายงานกรอบเวลาที่คุณได้รับจริง ถ้าคุณขอย้อนหลังหกเดือนแต่แผนของคุณเก็บข้อมูลไว้ 30 วัน มันจะคืน 30 วันและบอกคุณตรง ๆ

คำขอ

bash
# Inside your checkout handler, before you authorize the card
curl -s -H "Authorization: Bearer $TRACIO_SECRET_KEY" \
  "https://api.tracio.ai/v1/visitors/3f9a1b2c/velocity?window=24h"

การตอบกลับ

JSON
{
  "window": "24h",
  "events": 128,
  "uniqueIps": 4,
  "uniqueCountries": 2,
  "uniqueAccounts": 1,
  "meta": { "plan": "business", "retentionDays": 30 }
}

ตัวเลขชุดเดียวกันทุกที่

การเข้าชมที่ได้คะแนน 65.9 ในแดชบอร์ดของคุณ ก็ได้ 65.9 ใน Data API และ 65.9 ใน body ของ Webhook การเรนเดอร์สองทางที่แยกกันอาจค่อย ๆ เพี้ยนออกจากกันได้ โดยเรื่องสเกลคือกรณีคลาสสิก คือช่องทางหนึ่งให้คุณ 0.93 ขณะที่อีกช่องทางบอก 93 จึงมีการทดสอบความเท่าเทียมที่สร้างการเข้าชมหนึ่งครั้ง เรนเดอร์ผ่านทั้งสองช่องทาง แล้วเทียบฟิลด์สาธารณะบน JSON ดิบ ความตรงกันนี้ถูกบังคับด้วยการทดสอบ ไม่ใช่แค่ถูกกล่าวอ้าง

Guidance — Business ขึ้นไป

คำแนะนำ ไม่ใช่แค่ตัวเลข

คะแนนบอกคุณว่าเราเห็นอะไร ส่วน Guidance บอกคุณว่าควรทำอย่างไรกับสิ่งนั้น สำหรับสี่การตัดสินใจที่มีเงินเป็นเดิมพันจริง คำนวณด้วยกฎที่มีเวอร์ชันกำกับ พร้อมเหตุผลแนบมาด้วย

รับการชำระเงินนี้ไหม?

ชั่งน้ำหนักความเสี่ยง ชื่อเสียงด้านการฉ้อโกง และคำตัดสินเรื่องบอต ก่อนที่คุณจะอนุมัติบัตร

รับการสมัครนี้ไหม?

จับบัญชีใช้แล้วทิ้งได้ก่อนที่มันจะเกิดขึ้น การใช้หลายบัญชีและชื่อเสียงมีน้ำหนักมากที่สุดตรงนี้

ให้เข้าไหม?

เข้มขึ้นโดยอัตโนมัติเมื่อตัวตรวจจับการยึดบัญชีทำงานบนการเข้าชมนั้น

นับคอนเวอร์ชันนี้ไหม?

แยกการแนะนำที่แท้จริงออกจากการแนะนำตัวเอง หรือจากบอตที่ได้รับสิ่งจูงใจ

คำศัพท์สี่คำ

allowไม่มีอะไรที่ต้องลงมือ
challengeขอปัจจัยยืนยันที่สอง
reviewพักไว้ให้คนตรวจสอบ
denyปฏิเสธไปเลย

แต่ละสถานการณ์ได้คำตอบหนึ่งในสี่ พร้อมกับฐานที่ใช้ออกคำตอบนั้น คือแกนชี้ขาดจากชุดคำศัพท์ตายตัว ได้แก่ บอต ความเสี่ยง ชื่อเสียงด้านการฉ้อโกง พฤติกรรม การใช้หลายบัญชี การยึดบัญชี เครือข่าย และรูปแบบพันธมิตร คุณรู้เสมอว่าแกนไหนทำให้คำแนะนำขยับ โดยไม่ต้องเห็นชื่อสัญญาณ น้ำหนัก หรือเกณฑ์เลย

หนึ่งการคำนวณ สามช่องทาง

บล็อก Guidance ชุดเดียวกันเดินทางไปกับ Webhook ตอบใน Data API และแสดงบนการ์ดผู้เข้าชมในแดชบอร์ด คือกฎชุดเดียว ผลลัพธ์เดียว ไม่ต้องกระทบยอดอะไรฝั่งคุณ ให้อ่านคำแนะนำของสถานการณ์ที่คุณสนใจ ไม่ใช่ค่ารวม เพราะค่ารวมเป็นเพียงค่าที่เข้มที่สุดในสี่ค่า เป็นบทสรุปสำหรับแดชบอร์ด ไม่ใช่การตัดสินใจเรื่องการชำระเงิน เวอร์ชันของกฎถูกส่งมาใน payload ด้วย การเปลี่ยนกฎจึงเป็นสิ่งที่คุณสังเกตเห็น ไม่ใช่สิ่งที่คุณต้องอนุมานเอาจากคำแนะนำที่จู่ ๆ ก็ขยับ

JSON
"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 ฝั่งเซิร์ฟเวอร์ และนั่นเป็นความตั้งใจ แบ็กเอนด์ของคุณเชื่อมต่อผ่าน HTTP ธรรมดาด้วย Webhook ที่มีลายเซ็นและ Data API การตรวจสอบลายเซ็นใช้โค้ดราวสิบกว่าบรรทัดเทียบกับเวกเตอร์อ้างอิงที่เราเผยแพร่ไว้ และไม่มีอะไรเพิ่มเติมให้ต้องคอยอัปเกรดในต้นไม้ dependency ฝั่งเซิร์ฟเวอร์ของคุณ

SDK ฝั่งเบราว์เซอร์
JavaScriptReactVue 3AngularSvelte 5
ดู SDK ทั้งหมดเอกสารอ้างอิง APIเอกสาร Webhook
FAQ

คำถามที่พบบ่อย

ต่อระบบให้เสร็จได้ในบ่ายเดียว

สร้าง Webhook ในแดชบอร์ด ชี้ไปที่ endpoint ของคุณแล้วกด Test ตรวจสอบลายเซ็นเทียบกับเวกเตอร์อ้างอิงของเรา แล้วส่วนที่ยากก็ผ่านไปแล้ว

เริ่มทดลองใช้ฟรีจองการสาธิต