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

Saved Webhooks

Save named webhook endpoints once and reuse them for orders and email campaigns. Each webhook has its own URL, signing secret, custom headers, and test payload.

หน้าตั้งค่า Webhook ของ DabDash แสดง URL ปลายทาง สวิตช์เปิดใช้งาน secret สำหรับเซ็นลายเซ็น ปุ่มทดสอบ webhook และส่วน header ที่กำหนดเอง
ตั้งค่า Webhook — ตั้งค่าปลายทาง CRM, secret สำหรับเซ็นลายเซ็น และ header ที่กำหนดเองของคุณ

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 ล้มเหลว"