เว็บฮุกที่บันทึกไว้

Webhook ทำอะไร

Webhook เป็นวิธีที่ DabDash ใช้บอกระบบของคุณเอง — ไม่ว่าจะเป็น CRM เครื่องมือทำงานอัตโนมัติ หรือเซิร์ฟเวอร์ที่คุณทำเอง — ทันทีที่มีอะไรเกิดขึ้นในร้านของคุณ เมื่อลูกค้าสั่งออเดอร์ใหม่ DabDash จะส่งคำขอ HTTPS สั้น ๆ ไปที่ URL ที่คุณกำหนด แล้วระบบของคุณก็อ่านออเดอร์และทำอะไรกับมันก็ได้ตามใจ เช่น โยนเข้า CRM pipeline ส่งลิงก์ชำระเงิน เริ่มสั่งจัดส่ง หรือแจ้งเข้าช่อง Slack

ตอนนี้ DabDash ส่งเหตุการณ์เดียว — order.created — ในวินาทีที่ออเดอร์ถูกสั่ง ณ จุดนั้นออเดอร์อยู่ในสถานะ รอดำเนินการ การเปลี่ยนสถานะอื่น ๆ ยังไม่ยิง webhook (ในตอนนี้)

URL ปลายทาง

นี่คือ URL ที่ DabDash จะ POST ทุกออเดอร์ใหม่ไป มันต้องเป็น:

• HTTPS เท่านั้น — URL ที่เป็น http:// จะถูกปฏิเสธ
• เข้าถึงได้แบบสาธารณะ — เราบล็อกช่วง IP ภายใน (อะไรก็ตามที่อยู่บน 10.x, 172.16-31.x, 192.168.x, 127.x, link-local) CRM ของคุณต้องอยู่บนอินเทอร์เน็ตสาธารณะ
• คงที่ — ถ้า URL ของคุณเปลี่ยน ให้มาอัปเดตที่นี่ เราจะไม่ลองส่งซ้ำเมื่อล้มเหลวเกิน 4 ครั้ง

สวิตช์เปิดใช้งาน

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

Secret สำหรับเซ็นลายเซ็น

ทุกคำขอที่ DabDash ส่งไปยังปลายทางของคุณจะมี header ชื่อ X-DabDash-Signature มาด้วย header นี้บรรจุค่า HMAC-SHA256 ของเนื้อหาคำขอทั้งหมด คำนวณโดยใช้ secret ของคุณ เซิร์ฟเวอร์ของคุณควร:

1. อ่านเนื้อหาคำขอดิบ ๆ ก่อนจะแปลง JSON
2. คำนวณ sha256=HMAC-SHA256(body, secret)
3. เทียบค่าที่คำนวณได้กับ header X-DabDash-Signature โดยใช้การเทียบแบบ constant-time
4. ปฏิเสธคำขอถ้าค่าไม่ตรงกัน — นั่นแปลว่ามีคนอื่นที่ไม่ใช่ DabDash ส่งมา

คุณหมุนเปลี่ยน secret เมื่อไหร่ก็ได้ secret เก่าจะหยุดทำงาน ทันที — ไม่ใช่หลังหน่วงเวลา — ฉะนั้นเช็กให้แน่ใจว่าเซิร์ฟเวอร์ของคุณใช้ค่าใหม่แล้วก่อนกดปุ่มหมุนเปลี่ยน

การส่ง payload ทดสอบ

เมื่อคุณบันทึก URL และปลายทางของคุณพร้อมใช้งานแล้ว ให้คลิก ทดสอบ webhook เพื่อยิง payload order.created จำลองไปที่ปลายทางของคุณ payload จะถูกเซ็นด้วย secret ปัจจุบันของคุณ — เหมาะมากสำหรับยืนยันว่าโค้ดตรวจสอบลายเซ็นของคุณทำงานได้ก่อนที่ออเดอร์ลูกค้าจริงจะเข้ามา

ค่า order_number ของ payload จำลองคือ TEST-PING และในเนื้อหามี "test": true อยู่ ระบบปลายทางของคุณจะได้ข้ามมันไปได้

Header ที่กำหนดเอง (ขั้นสูง)

คลิก ขั้นสูง เพื่อเปิดส่วน header ที่กำหนดเอง CRM บางตัวต้องการ header เพิ่มเติมถึงจะยอมรับคำขอ — เช่น token แบบ Authorization: Bearer ... ตัวระบุร้านอย่าง X-Shop-Id: 42 หรือ API key แบบตายตัว เพิ่มคู่ชื่อ/ค่าได้สูงสุด 20 คู่ พวกมันจะถูกส่งไปกับทุกคำขอ webhook

มีชื่อ header อยู่ไม่กี่อันที่สงวนไว้และจะถูกปฏิเสธ: Host, Content-Type, Content-Length และ header อะไรก็ตามที่ขึ้นต้นด้วย X-DabDash- — DabDash คุมพวกนั้นเอง

ใน payload มีอะไรบ้าง

เนื้อหาเป็น JSON ฟิลด์ระดับบนสุด:

• event — ตอนนี้เป็น order.created เสมอ
• timestamp — วินาที Unix ตอนที่ webhook ถูกเตรียม
• tenant — { id, slug, name } ระบุร้านของคุณ
• order — { id, order_number, status, payment_method, subtotal_cents, total_cents, currency, customer, items, created_at }
• test — มีเฉพาะ (true) ตอนทดสอบ ping เท่านั้น

ความน่าเชื่อถือและการส่งซ้ำ

DabDash ลองส่งซ้ำเมื่อล้มเหลวด้วยการถ่างเวลาแบบ exponential backoff: รวม 4 ครั้ง โดยเว้นช่วง 1 นาที, 5 นาที และ 15 นาทีระหว่างแต่ละครั้ง เราลองส่งซ้ำเมื่อเจอข้อผิดพลาดเซิร์ฟเวอร์ 5xx และการเชื่อมต่อล้มเหลว แต่ ไม่ ลองซ้ำเมื่อได้ตอบ 4xx — 4xx แปลว่าปลายทางของคุณรับคำขอแล้วแต่ปฏิเสธเพราะอินพุตไม่ถูกต้อง ซึ่งเป็นปัญหาการตั้งค่า ไม่ใช่ความล้มเหลวชั่วคราว

หลังจากล้มเหลวครั้งสุดท้าย ออเดอร์ก็ดำเนินต่อตามปกติ — การส่ง webhook ไม่ขวางการชำระเงิน ความล้มเหลวจะโผล่ขึ้นในหน้ารายละเอียดออเดอร์ใต้หัวข้อ กิจกรรมการชำระเงิน ว่า "แจ้ง CRM ล้มเหลว"