# Webhook Automation
SUMMARY: ทริกเกอร์ระบบภายนอกเมื่อ memory เปลี่ยนแปลง — sync, แจ้งเตือน, ทำให้เป็นอัตโนมัติ

Webhook Automation
Webhook ช่วยให้คุณทริกเกอร์ระบบภายนอกเมื่อ Synapse event ทำงาน คู่มือนี้ครอบคลุมรูปแบบ automation ทั่วไป
รูปแบบทั่วไป
รูปแบบ 1: แจ้งเตือนเมื่อ Memory Critical
ส่งข้อความ Slack เมื่อ memory critical ถูกเก็บ:
[CODE BLOCK]
ลงทะเบียน webhook:
[CODE BLOCK]
รูปแบบ 2: Sync ไปยังระบบภายนอก
Sync memory ไปยัง Notion, Obsidian หรือ KB ภายนอกใด ๆ:
[CODE BLOCK]
รูปแบบ 3: ทริกเกอร์ CI/CD
ทริกเกอร์ deployment เมื่อ memory "release" ถูกเก็บ:
[CODE BLOCK]
รูปแบบ 4: ปลุก Agent เมื่อ Human ส่งข้อความ
ทริกเกอร์การรัน LLM agent เมื่อ human ส่งข้อความแช็ต:
[CODE BLOCK]
รูปแบบ 5: รวม Metric
ติดตามการเติบโตของ memory, กิจกรรมแช็ต, การทำ task เสร็จ:
[CODE BLOCK]
การตรวจสอบ Signature
ตรวจสอบ webhook signature เสมอเพื่อป้องกันการปลอมแปลง:
[CODE BLOCK]
ตรรกะ Retry
Synapse retry webhook ที่ล้มเหลวด้วย exponential backoff handler ของคุณควร:
1. ส่งกลับ 200 อย่างรวดเร็ว — อย่าทำงานหนักแบบ synchronous
2. จัดคิวงาน — ใช้ระบบ background job
3. เป็น idempotent — event เดียวกันอาจถูกส่งสองครั้ง
[CODE BLOCK]
Debugging Webhook
ตรวจสอบประวัติการจัดส่ง
การจัดส่ง webhook ถูกบันทึก ตรวจสอบการจัดส่งล่าสุดของ webhook:
[CODE BLOCK]
ทดสอบ webhook ด้วยตนเอง
[CODE BLOCK]
ปัญหาทั่วไป
| ปัญหา | วิธีแก้ |
|-------|-----|
| 4xx response | ตรวจ handler ส่งกลับ 200 |
| 5xx response | server error — ตรวจ log แอป |
| Timeout | ส่งกลับ 200 เร็ว, จัดคิวงาน async |
| การจัดส่งซ้ำ | ทำ handler idempotent |
| Signature ไม่ตรง | ตรวจ secret ถูกต้อง |
แนวทางปฏิบัติที่ดีที่สุด
> [!TIP]
> - ตรวจสอบ signature เสมอ — อย่าข้ามสิ่งนี้
> - ส่งกลับ 200 เร็ว — อยะบล็อก Synapse
> - เป็น idempotent — จัดการการจัดส่งซ้ำ
> - ใช้ event เฉพาะ —  ไม่ใช่ 
> - ตรวจสอบการล้มเหลวการจัดส่ง — ตั้งค่า alerting
ขั้นตอนถัดไป
- Webhooks API
- Cron & Scheduler
- Persistent LLM Agent