# Event Triggers บน Garudust

> Source: <https://dev.to/garudust/event-triggers-bn-garudust-4ji3>
> Published: 2026-05-23 03:24:03+00:00

core ของ Garudust เปิดเผย primitive พื้นฐานตัวเดียว: agent.run(task)
ทุก entry point — ไม่ว่าจะเป็นข้อความจากแชท, cron job, หรือ webhook call — ล้วนลงเอยที่ call เดียวกันนี้ทั้งสิ้น นั่นหมายความว่าระบบภายนอกใดก็ตามที่ส่ง HTTP POST ได้ ก็สามารถเป็น event trigger ให้ Garudust ได้เลย
บทความนี้จะอธิบายว่ามันทำงานอย่างไรในปัจจุบัน, pattern ที่ใช้งานได้จริงใน production และ use case ที่เป็นรูปธรรม
เมื่อ Garudust ถูกตั้งค่าให้ใช้ webhook platform มันจะเปิด Axum HTTP server และลงทะเบียน POST endpoint ไว้ที่ path ที่คุณกำหนด request ขาเข้าจะมีหน้าตาแบบนี้:
{
"text": "A new billing invoice has arrived from Acme Corp for $4,200.",
"callback_url": "https://your-system.example.com/garudust/reply",
"user_id": "billing-watcher",
"session_key": "billing-acme-corp"
}
Garudust จะห่อข้อมูลนี้เป็น InboundMessage
, ส่งผ่าน GatewayHandler
, spawn agent.run()
ขึ้นมา และเมื่อ agent ทำงานเสร็จก็จะ POST คำตอบกลับไปที่ callback_url
:
{
"text": "Invoice from Acme Corp for $4,200 — categorised as SaaS/Infrastructure. Flagged for approval above $3,000 threshold. Draft approval request sent to #finance."
}
HTTP response ที่ตอบกลับ POST ของคุณทันทีคือ 202 Accepted
— agent ทำงานแบบ asynchronous
Garudust ตรวจสอบ HMAC-SHA256 signature ทุก request ที่เข้ามา ตั้ง shared secret ใน config แล้ว sign ทุก POST ขาออกด้วย:
X-Hub-Signature-256: sha256=<hex(HMAC-SHA256(secret, raw_body))>
Request ที่ไม่มี signature ถูกต้องจะถูกปฏิเสธด้วย 401
และ callback URL ที่ชี้ไป private IP (192.168.x.x
, 10.x.x.x
, localhost
) ก็ถูก block โดย network guard ด้วย — agent ไม่สามารถถูกบังคับให้ call back หา internal infrastructure ได้
การแบ่งหน้าที่ชัดเจนมาก:
ระบบภายนอก Garudust
───────────────── ──────────────────────────
Event source (email, → Webhook adapter
calendar, DB, queue)
Filter / match logic → โค้ดของคุณ (ก่อน POST)
Task description → agent.run(task)
Result handling → handler ที่ callback_url ของคุณ
ระบบของคุณเป็นเจ้าของ filter — Garudust เป็นเจ้าของการรัน agent ทั้งสองฝั่งไม่จำเป็นต้องรู้โครงสร้างภายในของกันและกันเลย
บริการประมวลผลอีเมลคอยดักจับอีเมลจากผู้ส่งที่เป็นระบบ billing เมื่อเจออีเมลที่ match ก็ดึง subject, ผู้ส่ง และจำนวนเงิน แล้ว trigger Garudust:
{
"text": "New invoice received: Stripe — $1,840 for May 2026. Attach to this month's expense report and notify the finance channel if it exceeds the $1,500 alert threshold.",
"callback_url": "https://your-ops.example.com/hooks/garudust",
"session_key": "finance-inbox"
}
Agent ใช้ tool ของมันอ่านไฟล์ expense report, เพิ่ม line item และโพสต์แจ้ง Slack บริการอีเมลทำแค่ match ผู้ส่งแล้วยิง — ไม่ต้องรู้อะไรเกี่ยวกับ expense report หรือ Slack เลย
GitHub Actions workflow เรียก Garudust หลังมี PR เปิดเข้ามาที่ branch main
โดย workflow สร้าง payload จาก GitHub context:
{
"text": "PR #214 opened by @alice: 'feat: add OAuth2 PKCE flow'. Changed files: src/auth/oauth.rs, src/auth/pkce.rs, tests/auth_integration.rs. Diff summary attached. Review for security issues in the auth flow and post a summary comment.",
"callback_url": "https://your-ci.example.com/garudust/pr-review",
"session_key": "pr-214"
}
webhook ของ GitHub ยิง workflow → workflow สร้าง task text → Garudust รีวิว และ session_key
ที่ผูกกับเลข PR ทำให้ trigger ครั้งถัดไป (commit ใหม่, ขอรีวิวซ้ำ) ต่อเนื่องใน conversation thread เดิม
Monitoring job query ฐานข้อมูลตามตาราง schedule แล้วตรวจ aggregate metric เมื่อ metric ข้ามเกณฑ์ แทนที่จะส่ง static alert มันยิง Garudust แทน:
{
"text": "Anomaly detected: orders table insert rate dropped 94% in the last 10 minutes (baseline 340/min, current 19/min). Last successful insert: 09:42 UTC. Investigate root cause and summarise for on-call.",
"callback_url": "https://ops.example.com/garudust/incidents",
"session_key": "incident-2026-05-23-orders"
}
Agent สามารถใช้ terminal หรือ database tool รัน query เพิ่มเติม, ตรวจ deploy ล่าสุด และสรุป incident แบบมีโครงสร้าง — monitoring job ทำแค่ตรวจ threshold breach เท่านั้น
Integration layer poll Google Calendar (หรือรับ push notification) แล้วยิง Garudust เมื่อมี event ถูกสร้างขึ้นพร้อม attendee ที่ domain ไม่ตรงกับองค์กรของคุณ:
{
"text": "New calendar event: 'Q3 partnership discussion' on 2026-06-04 14:00 UTC. External attendees: jane@partner.com, bob@partner.com. Prepare a one-page briefing on Partner Corp using the CRM notes and recent email thread.",
"callback_url": "https://your-system.example.com/garudust/calendar",
"session_key": "meeting-prep-2026-06-04"
}
Calendar integration เป็นเจ้าของ logic กรอง "external attendee" — Garudust เป็นเจ้าของการสร้าง briefing
Background worker ดึงงานออกจาก task queue (SQS, Redis, RabbitMQ) แล้วส่งแต่ละชิ้นให้ Garudust ทำ เหมาะกับงานที่ปริมาณผันแปรและต้องการให้ agent จัดการแต่ละชิ้นในแบบของตัวเอง:
{
"text": "Customer support ticket #8821 (priority: high): User reports that export to CSV silently truncates rows above 10,000. Reproduce the scenario, identify the code path responsible, and draft a fix description for the engineering team.",
"callback_url": "https://support.example.com/garudust/tickets",
"session_key": "ticket-8821"
}
Queue worker dequeue, จัดรูป task text, ยิง webhook หลาย ticket สามารถรันเป็น concurrent agent session พร้อมกันได้
session_key
คือสิ่งที่ทำให้ event trigger มีประโยชน์เกินกว่างานแบบ one-shot เมื่อคุณตรึง key ไว้ webhook call ทั้งหมดที่ใช้ key เดียวกันจะแชร์ conversation history ร่วมกัน หมายความว่า:
ถ้าต้องการแยก session ออกจากกันสมบูรณ์ (แต่ละ event เป็นอิสระ) ก็ไม่ต้องระบุ session_key
— Garudust จะใช้ callback_url
เป็น key แทน ทำให้ได้ context ใหม่ต่อ callback target ที่ไม่ซ้ำกัน
Webhook adapter คือ push target — ระบบภายนอกต้องเป็นฝ่ายเริ่มการเชื่อมต่อ ถ้าต้องการให้ Garudust ดึงข้อมูลจากแหล่งต้นทางเอง (ตรวจ inbox, poll API, เฝ้าดูไฟล์) โดยไม่ต้องมี scheduler นั้นต้องใช้ cron job ที่คอย poll หรือรอ primitive watch
/filter
ที่ยังไม่มีในปัจจุบัน
สำหรับ use case ที่เป็น push-based จริงๆ (GitHub webhook, queue worker, calendar push notification, email routing service) สถาปัตยกรรมปัจจุบันรองรับได้ครบและการแบ่งหน้าที่ก็ชัดเจนดีอยู่แล้ว