Webhook

นิยามของ Webhook

Webhook คือกลไกที่ระบบหนึ่งจะ "ส่งข้อมูลไปหาอีกระบบหนึ่งโดยอัตโนมัติ" ทันทีที่เกิดเหตุการณ์ที่กำหนดไว้ แทนที่ฝั่งผู้รับจะต้องคอยถามซ้ำ ๆ ว่า "มีอะไรใหม่หรือยัง" ระบบต้นทางจะยิง HTTP POST ไปยัง URL ปลายทางที่เราเตรียมไว้เอง

พูดแบบชาวร้านออนไลน์: Webhook คือ "พนักงานส่งของส่วนตัว" ที่วิ่งไปบอกระบบหลังบ้านของคุณทันทีที่มีออเดอร์ใหม่ ของถูกจัดส่ง หรือลูกค้าขอคืนสินค้า โดยไม่ต้องรอให้คุณเปิดหลังบ้านเช็กเอง

พารามิเตอร์หลักที่ต้องรู้

- Endpoint URL: ที่อยู่ปลายทางที่รับข้อมูล เช่น https://yourstore.com/webhooks/orders

- Event Trigger: เหตุการณ์ที่ทำให้ยิง เช่น order.created, shipment.updated

- Payload: ข้อมูลที่ส่งมา มักเป็น JSON

- Signature / Secret: รหัสลับสำหรับตรวจสอบว่าข้อมูลมาจากแหล่งที่เชื่อถือได้

- Response Code: ปลายทางต้องตอบ 200 OK ภายใน 5–10 วินาที ถือว่ารับสำเร็จ

เปรียบเทียบให้เห็นภาพ

ลองนึกภาพร้านกาแฟหน้าโรงเรียน

- แบบไม่มี Webhook (Polling): คุณจ้างเด็กวิ่งไปถามร้านทุก 5 นาทีว่า "มีออเดอร์ใหม่ไหม" เสียแรง เสียเวลา เปลืองทรัพยากร

- แบบมี Webhook: ร้านกาแฟโทรหาคุณทันทีที่มีลูกค้าสั่ง เด็กวิ่งไปครั้งเดียว ได้ของกลับมาเลย

ในโลกเทคนิค Polling คือการที่ระบบคุณยิง API ไปถามทุก ๆ N วินาที ส่วน Webhook คือระบบต้นทางเป็นฝ่าย "ผลัก" ข้อมูลมาให้คุณ

สูตรคำนวณที่ควรรู้

1) อัตราการประหยัด Request จาก Webhook

Savings (%) = ((Polling_Requests - Webhook_Requests) / Polling_Requests) × 100

ตัวอย่างจริง: ร้าน Shopify ที่มียอด 500 ออเดอร์/วัน

- Polling ทุก 60 วินาที = 1,440 requests/วัน

- Webhook = 500 requests/วัน (ยิงตามออเดอร์จริง)

- Savings = ((1,440 - 500) / 1,440) × 100 ≈ 65.3%

2) Latency เปรียบเทียบ

Latency_avg = Polling_Interval / 2

ถ้า Polling ทุก 5 นาที (300 วินาที) เวลารอเฉลี่ย = 150 วินาที

Webhook ทำงานภายใน ไม่เกิน 2 วินาที หลังเหตุการณ์เกิด → เร็วกว่า 75 เท่า

3) Throughput ที่รองรับได้

Max_Throughput = (3600 / Avg_Processing_Time) × Concurrent_Workers

ตัวอย่าง: ประมวลผล 1 webhook ใช้เวลา 0.2 วินาที, มี 10 workers

→ Max = (3600 / 0.2) × 10 = 180,000 webhooks/ชั่วโมง

ตารางเปรียบเทียบ Webhook vs Polling vs WebSocket

应用场景: ใช้จริงในธุรกิจ DTC / E-commerce

1. ออเดอร์ใหม่จาก Shopify → ระบบ ERP

เมื่อลูกค้ากดสั่งซื้อ Shopify ยิง orders/create ไปที่ ERP ภายใน ไม่เกิน 1.8 วินาที สต็อกถูกตัด ใบปะหน้าถูกสร้าง พนักงานแพ็คเห็นออเดอร์ทันที

2. อัปเดตสถานะพัสดุจาก Kerry / Flash / SCG Express

ทุกครั้งที่พัสดุเปลี่ยนสถานะ (รับเข้า → กำลังขนส่ง → ส่งสำเร็จ) ระบบขนส่งยิง webhook เข้ามา ลูกค้าได้รับอีเมล/SMS ทันที ลด call center เรื่อง "พัสดุอยู่ไหน" ได้ถึง 42%

3. การชำระเงินผ่าน Omise / 2C2P / Stripe

เมื่อตัดบัตรสำเร็จ ระบบ payment gateway ยิง charge.complete มาให้ ระบบคุณเปลี่ยนสถานะออเดอร์เป็น "ชำระแล้ว" ภายใน 0.9 วินาที ลดปัญหาลูกค้าโอนแล้วแต่ออเดอร์ค้าง

4. ซิงก์ข้อมูลลูกค้ากับ CRM

ลูกค้ากรอกฟอร์มบน Landing Page → webhook ส่งข้อมูลเข้า HubSpot / Salesforce ทันที ทีมขายโทรตามภายใน ไม่เกิน 60 วินาที เพิ่มโอกาสปิดการขายได้ 7 เท่า เทียบกับติดตามภายใน 1 ชั่วโมง

5. แจ้งเตือนสต็อกต่ำ

เมื่อสต็อกต่ำกว่า 10 ชิ้น ระบบยิง webhook เข้า LINE Notify ของทีมคลังสินค้า ป้องกัน of stock ในช่วง flash sale

ข้อเข้าใจผิดที่พบบ่อย

1. "ยิง webhook แล้วต้องสำเร็จเสมอ"

ผิด ฝั่งผู้รับอาจล่ม ตอบ 500 หรือ timeout ระบบที่ดีต้องมี Retry Policy เช่น retry 3 ครั้งที่ 1s, 10s, 60s และมี Dead Letter Queue เก็บตัวที่ fail

2. "ไม่ต้องตรวจ signature ก็ได้"

อันตรายมาก ใครก็ยิง payload ปลอมเข้ามาได้ ต้องตรวจ HMAC-SHA256 ด้วย secret ที่แชร์กัน

3. "ตอบ 200 แล้วคือจบ"

ไม่จริง ควรตอบ 200 เร็ว ๆ แล้วประมวลผลแบบ async ผ่าน queue (เช่น RabbitMQ, SQS) ถ้าประมวลผลนานเกิน 10 วินาที ต้นทางมักถือว่า timeout

4. "Webhook แทน API ได้ทั้งหมด"

Webhook เป็นแค่ "การแจ้งเตือน" ถ้าต้องดึงข้อมูลย้อนหลัง ต้องใช้ REST API เสริม

5. "ตั้ง URL เดียวใช้ได้ทุก event"

ควรแยก endpoint ตามประเภท event เพื่อ debug ง่าย และตั้ง firewall/rate limit แยกกัน

6. "Idempotency ไม่สำคัญ"

สำคัญมาก webhook อาจถูกส่งซ้ำ (at-least-once delivery) ต้องใช้ event_id เช็กก่อนประมวลผล ไม่งั้นลูกค้าอาจได้สินค้าซ้ำหรือตัดสต็อกซ้ำ

术语相关

- API (Application Programming Interface): ช่องทางให้ระบบคุยกัน ปกติเป็น request-response

- Endpoint: URL ปลายทางที่รับ webhook

- Payload: ข้อมูลที่ส่งมาในรูปแบบ JSON/XML

- HMAC Signature: ลายเซ็นตรวจสอบความถูกต้องของ payload

- Retry & Backoff: กลไกส่งซ้ำเมื่อปลายทางล่ม

- Idempotency Key: คีย์กันประมวลผลซ้ำ

- Dead Letter Queue (DLQ): คิวเก็บ webhook ที่ประมวลผลไม่สำเร็จ

- Event Bus: ระบบกลางกระจาย event ไปหลายผู้รับ

- Rate Limiting: จำกัดจำนวน request ต่อวินาที

- Polling: วิธีตรงข้ามที่ฝั่งผู้รับต้องถามเอง

- WebSocket: ช่องทางสองทางสำหรับ real-time

- Zapier / Make: เครื่องมือ no-code ที่รับส่ง webhook

สรุปสำหรับคนทำร้าน DTC

Webhook คือเครื่องมือที่ทำให้หลังบ้านของคุณ "รู้ทันที" โดยไม่ต้องนั่งเฝ้า ถ้าออเดอร์ของคุณเกิน 100 ออเดอร์/วัน หรือมีพาร์ตเนอร์โลจิสติกส์มากกว่า 2 เจ้า การใช้ webhook จะลดเวลาทำงาน manual ได้ 60–80% และลด human error จากการคีย์ข้อมูลซ้ำได้อย่างชัดเจน

เริ่มต้นง่าย ๆ: เปิด webhook จาก Shopify → รับที่ Make หรือ n8n → ตรวจ signature → เก็บ log ทุก event ไว้อย่างน้อย 30 วัน เพื่อ debug และทำ audit

ทำให้ถูกตั้งแต่แรก ระบบจะโตไปกับร้านคุณได้แบบไม่ต้องรื้อใหม่