การติดตามการจัดส่งด้วย Webhook: Webhook สำหรับการติดตามทำงานอย่างไรเมื่อเทียบกับ Polling (Payloads, การลองส่งซ้ำ และการตั้งค่า)

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

ไม่มีวิธีใดทำให้ผู้ให้บริการขนส่งสแกนพัสดุได้เร็วขึ้น ทั้งสองวิธีขึ้นอยู่กับเวลาที่แหล่งข้อมูลการติดตามได้รับและเปิดเผยข้อมูลใหม่ ความแตกต่างในทางปฏิบัติคือวิธีที่แอปพลิเคชันของคุณเรียนรู้ข้อมูลดังกล่าว ปริมาณทราฟฟิกคำขอที่สร้างขึ้น และสิ่งที่เกิดขึ้นเมื่อการส่งข้อมูลล้มเหลว

Webhook ติดตามกับ Polling: ความแตกต่างในการดำเนินงาน

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

เลือก Webhook ก่อน เมื่อการอัปเดตที่รวดเร็วมีความสำคัญและทีมของคุณสามารถดูแลตัวรับที่เชื่อถือได้ เลือก Polling ก่อน เมื่อ Endpoint ขาเข้าไม่สะดวก ปริมาณการจัดส่งมีไม่มาก หรือแหล่งข้อมูลไม่มี Webhook ที่เหมาะสม ใช้การออกแบบแบบผสม เมื่อการพลาดการอัปเดตจะรบกวนการสื่อสารกับลูกค้าหรือการดำเนินงาน และ API รองรับการตรวจสอบความสอดคล้อง

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

เกิดอะไรขึ้นระหว่างการสแกนของผู้ให้บริการขนส่งกับแอปพลิเคชันของคุณ

1. ระบุการจัดส่ง เชื่อมโยงหมายเลขติดตาม ข้อมูลผู้ให้บริการขนส่งเมื่อจำเป็น และข้อมูลอ้างอิงการจัดส่งภายใน บริการบางแห่งต้องลงทะเบียนก่อนเริ่มการตรวจสอบ
2. กำหนดค่าการส่งเหตุการณ์ ระบุ URL Callback แบบ HTTPS และเลือกการสมัครรับเหตุการณ์ที่รองรับ
3. แหล่งข้อมูลได้รับข้อมูลการติดตาม การสแกนของผู้ให้บริการขนส่งหรือการเปลี่ยนแปลงสถานะพร้อมใช้งานสำหรับบริการติดตาม
4. บริการส่ง Webhook คำขออาจมีภาพรวมการติดตามทั้งหมด จุดตรวจสอบเพียงจุดเดียว หรือมีเพียงข้อมูลอ้างอิงที่ต้องเรียกดูผ่าน API
5. ตัวรับของคุณตรวจสอบและจัดเก็บข้อมูล ยืนยันสิทธิ์คำขอ ตรวจสอบโครงสร้าง และบันทึกหรือเข้าคิวเหตุการณ์อย่างถาวร
6. Worker อัปเดตระบบธุรกิจ ปรับสถานะให้เป็นรูปแบบมาตรฐาน อัปเดตระเบียนการจัดส่ง และเรียกใช้เฉพาะการดำเนินการที่ยังเหมาะสม

การส่ง Webhook ไม่เหมือนกับการจัดส่งทางกายภาพ แต่เป็นข้อความเกี่ยวกับข้อมูลการจัดส่ง ในทำนองเดียวกัน การตอบกลับ Webhook สำเร็จไม่ได้พิสูจน์ว่าอีเมลถูกส่งแล้วหรือระเบียนคำสั่งซื้อได้รับการอัปเดตแล้ว สิ่งเหล่านี้เป็นผลลัพธ์ของการประมวลผลภายหลังซึ่งต้องมีการตรวจสอบของตนเอง

การอ่าน Payload ของ Webhook ติดตาม

JSON ต่อไปนี้เป็นการออกแบบการผสานรวมเพื่อประกอบการอธิบาย ไม่ใช่ Payload ของ 17TRACK หรือ Schema สากล ชื่อฟิลด์จริง รหัสสถานะ รูปแบบเวลา และตัวระบุเหตุการณ์ต้องอ้างอิงจากเอกสารของผู้ให้บริการที่เลือก

{
  "event_id": "evt_example_001",
  "event_type": "shipment.updated",
  "created_at": "2025-04-08T10:16:00Z",
  "shipment": {
    "reference": "shipment_example_123",
    "tracking_number": "EXAMPLE123456",
    "carrier_code": "example_carrier",
    "status": "in_transit",
    "checkpoint": {
      "occurred_at": "2025-04-08T10:10:00Z",
      "description": "Departed processing facility"
    }
  }
}

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

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

เก็บสถานะและคำอธิบายดั้งเดิมไว้ควบคู่กับสถานะธุรกิจที่ปรับเป็นมาตรฐานแล้ว แอปพลิเคชันของคุณอาจแมปข้อความจากผู้ให้บริการหลายรายการเป็น “อยู่ระหว่างการขนส่ง” แต่เจ้าหน้าที่ฝ่ายสนับสนุนอาจยังต้องใช้จุดตรวจสอบดั้งเดิมเพื่อทำความเข้าใจความล่าช้า ถือว่าวันที่จัดส่งโดยประมาณเป็นเพียงการประมาณการ และแยกความแตกต่างระหว่างฟิลด์ที่หายไปกับคำสั่งอย่างชัดเจนให้ล้างค่าที่มีอยู่

การลองส่งซ้ำ การตอบรับ และเหตุการณ์ซ้ำ

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

ตอบรับหลังจากยอมรับข้อมูลอย่างถาวร

ทำให้เส้นทางคำขอสั้น ได้แก่ ตรวจสอบคำขอ บันทึกงานที่ยอมรับอย่างถาวร และส่งการตอบกลับสำเร็จตามที่ผู้ให้บริการกำหนด ส่งอีเมลและดำเนินการทางธุรกิจที่ใช้เวลานานแบบ Asynchronous ข้อกำหนด HTTP ระบุว่า 202 Accepted หมายถึงการยอมรับเพื่อประมวลผล ไม่ใช่การประมวลผลเสร็จสมบูรณ์ แต่ผู้ให้บริการของคุณอาจกำหนดการตอบกลับสำเร็จแบบอื่น ให้ปฏิบัติตามสัญญา Webhook ของผู้ให้บริการ

การส่งการตอบกลับสำเร็จก่อนจัดเก็บข้อมูลใด ๆ เสี่ยงต่อการสูญเสียการอัปเดตหากกระบวนการของคุณหยุดทำงาน การรอให้การดำเนินการภายหลังทั้งหมดเสร็จสิ้นเสี่ยงต่อการหมดเวลาและการส่งซ้ำอีกครั้ง Inbox หรือ Queue ที่จัดเก็บอย่างถาวรจะสร้างขอบเขตระหว่างการรับข้อมูลกับการประมวลผล

ทำให้การประมวลผลเป็น Idempotent

Idempotency หมายถึงการประมวลผลเหตุการณ์เดิมอีกครั้งจะไม่ทำให้เกิดผลกระทบทางธุรกิจซ้ำ ผู้ส่งอาจลองส่งซ้ำหลังจากเซิร์ฟเวอร์ของคุณยอมรับเหตุการณ์แล้ว แต่การตอบรับสูญหาย ดังนั้นการส่งข้อมูลซ้ำควรเป็นกรณีทดสอบตามปกติ

• ใช้ตัวระบุเหตุการณ์ที่มีการบันทึกไว้เป็นคีย์สำหรับกำจัดข้อมูลซ้ำเมื่อมีตัวระบุดังกล่าว โดยกำหนดขอบเขตให้ตรงกับผู้ให้บริการหรือบัญชีที่ถูกต้อง
• หากไม่มีตัวระบุ ให้สร้างคีย์ผสมจากฟิลด์เหตุการณ์ที่คงที่ และทดสอบความเสี่ยงจากการชนกันของคีย์
• บังคับใช้ความไม่ซ้ำกันแบบ Atomic ในพื้นที่จัดเก็บ ลำดับการ “ตรวจสอบแล้วจึงแทรก” แยกกันอาจเกิด Race Condition เมื่อมีการส่งพร้อมกัน
• ป้องกันการดำเนินการภายหลังด้วย เหตุการณ์ซ้ำต้องไม่ส่งการแจ้งเตือนการจัดส่งอีกครั้งหรือดำเนินการทางการเงินซ้ำ
• กำหนดระยะเวลาการเก็บรักษาตามพฤติกรรมการ Replay ของผู้ให้บริการและข้อกำหนดด้านการกู้คืนของคุณ แทนการลบบันทึกกำจัดข้อมูลซ้ำทันที

อย่าสมมติว่าข้อมูลมาถึงตามลำดับเวลา

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

รายการตรวจสอบการตั้งค่าที่ใช้งานได้จริง

1. ยืนยันสัญญาของผู้ให้บริการ

ก่อนเริ่มใช้งาน ให้ยืนยันข้อกำหนดการลงทะเบียน เหตุการณ์ที่รองรับ รูปแบบ Payload การยืนยันตัวตน ความคาดหวังต่อการตอบกลับ ระยะหมดเวลา พฤติกรรมการลองส่งซ้ำ และขีดจำกัดของ API ตรวจสอบว่าการแจ้งเตือนแสดงภาพรวมสถานะหรือการเปลี่ยนแปลงแบบเพิ่มทีละส่วน การส่งข้อมูลสามารถมีหลายระเบียนได้หรือไม่ และการสมัครรับข้อมูลจะส่งสถานะเริ่มต้นหรือไม่

สำหรับการผสานรวมกับ 17TRACK ให้เริ่มจาก หน้า Tracking API อย่างเป็นทางการ และ เอกสาร API ใช้เอกสารเฉพาะของผู้ให้บริการเพื่อกำหนดฟิลด์คำขอและข้อกำหนด Callback Payload ทั่วไปข้างต้นไม่ใช่สิ่งทดแทน ยืนยันเงื่อนไขการเข้าถึงและขีดจำกัดการดำเนินงานสำหรับการผสานรวมที่คุณตั้งใจจะนำไปใช้งาน

2. รักษาความปลอดภัยให้ Endpoint ที่รับข้อมูล

ใช้ HTTPS และกลไกการยืนยันตัวตนที่ผู้ให้บริการระบุ หากใช้ลายเซ็น HMAC ให้ตรวจสอบอินพุตที่ลงนามตามที่ระบุอย่างเคร่งครัด เมื่อมีการลงนามไบต์ดิบของคำขอ การแยกวิเคราะห์และจัดทำ JSON ใหม่ก่อนการตรวจสอบอาจเปลี่ยนแปลงไบต์เหล่านั้นและทำให้ลายเซ็นไม่ถูกต้อง ใช้การเปรียบเทียบแบบใช้เวลาคงที่สำหรับค่าลายเซ็นที่สร้างจาก Secret

หากมี Timestamp ที่ลงนามหรือตัวระบุการส่งข้อมูล ให้ใช้การควบคุม Replay ตามที่ระบุไว้ ลายเซ็นที่ถูกต้องยืนยันความถูกต้องของข้อความ แต่ไม่ได้ยืนยันด้วยตัวมันเองว่าข้อความนั้นเป็นข้อมูลใหม่ เก็บ Secret ให้ห่างจาก URL และ Application Log รองรับการหมุนเวียน Secret และจำกัดขนาดคำขอ การอนุญาตเฉพาะ IP อาจเป็นการควบคุมเพิ่มเติมเมื่อมีช่วงที่อยู่ที่ดูแลได้ ไม่ใช่สิ่งทดแทนการยืนยันตัวตนของข้อความ

3. แยกการรับข้อมูลออกจากการประมวลผลทางธุรกิจ

จัดเก็บข้อมูลให้เพียงพอสำหรับการติดตามและ Replay เหตุการณ์ที่ยอมรับอย่างปลอดภัย Worker ของ Queue ควรปรับการอัปเดตให้เป็นมาตรฐาน ใช้กฎการเปลี่ยนสถานะ และบันทึกผลลัพธ์ของการดำเนินการ นำงานที่ล้มเหลวซ้ำ ๆ ไปไว้ในกระบวนการ Dead-letter ที่ตรวจสอบได้ แทนการลองซ้ำไม่สิ้นสุด จำกัดการเข้าถึงและระยะเวลาการเก็บรักษา เนื่องจาก Payload การติดตามอาจมีข้อมูลที่เกี่ยวข้องกับลูกค้า

4. ทดสอบเส้นทางข้อผิดพลาดก่อนเปิดใช้งาน

• ส่งเหตุการณ์เดิมสองครั้ง รวมถึงการส่งพร้อมกัน
• ส่งจุดตรวจสอบที่เก่ากว่าหลังจุดตรวจสอบที่ใหม่กว่า
• จำลอง Queue ขัดข้องและ Worker หยุดทำงานหลังรับข้อมูล
• ทดสอบการยืนยันตัวตนที่ไม่ถูกต้อง JSON ที่มีรูปแบบผิด และคำขอที่มีขนาดใหญ่เกินไป
• ทดสอบการจัดส่งที่ไม่รู้จัก ฟิลด์เสริมที่หายไป และฟิลด์ที่เพิ่มเข้ามา
• ตรวจสอบว่าพัสดุที่จัดส่งแล้วหนึ่งชิ้นไม่ทำให้คำสั่งซื้อที่แบ่งการจัดส่งเสร็จสมบูรณ์
• Replay เหตุการณ์หลังการกู้คืน และยืนยันว่าการแจ้งเตือนยังคงถูกกำจัดข้อมูลซ้ำ

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

กรณีที่ Polling ยังคงมีประโยชน์

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

สำหรับการวางแผนขนาด ระบบ Polling แบบง่ายคือ requests per hour ≈ active shipments × polls per shipment per hour โดยสมมติว่าหนึ่งคำขอต่อหนึ่งการจัดส่ง Endpoint แบบ Batch จะเปลี่ยนการคำนวณนี้ ตัวอย่างเช่น การตรวจสอบการจัดส่ง 1,000 รายการชั่วโมงละสี่ครั้งจะสร้างคำขอ 4,000 ครั้งต่อชั่วโมงก่อนการลองส่งซ้ำ นี่เป็นเพียงการคำนวณทางคณิตศาสตร์ ไม่ใช่โควตาหรือการประเมินราคาโดยผู้ให้บริการ

กำหนดเวลาการตรวจสอบตามกิจกรรมของการจัดส่งและความเสี่ยงทางธุรกิจ เคารพขีดจำกัดอัตราการเรียกใช้ และเพิ่ม Jitter เพื่อไม่ให้งานทั้งหมดเริ่มพร้อมกัน สำหรับข้อผิดพลาดที่ลองใหม่ได้ ให้ใช้ Backoff ที่มีขอบเขตและปฏิบัติตามคำแนะนำของเซิร์ฟเวอร์ที่เกี่ยวข้อง อย่าลองซ้ำข้อผิดพลาดถาวรด้านข้อมูลรับรองหรือการตรวจสอบความถูกต้องซ้ำ ๆ โดยไม่แก้ไขสาเหตุ

ระบบแบบผสมที่ใช้งานได้จริงใช้ Webhook สำหรับการอัปเดตตามปกติ และใช้การอ่าน API แบบเจาะจงสำหรับช่องว่างที่สงสัย ตรวจสอบความล้มเหลวในการรับข้อมูล อายุของ Queue ความล้มเหลวในการประมวลผล อัตราเหตุการณ์ซ้ำ และความไม่ตรงกันในการตรวจสอบความสอดคล้องแยกจากกัน เมื่อ Timestamp เชื่อถือได้ ให้แยกความล่าช้าของข้อมูลต้นทาง ความล่าช้าในการส่ง Webhook และความล่าช้าในการประมวลผลภายในออกจากกัน

คำถามที่พบบ่อย

Webhook ติดตามเป็นแบบเรียลไทม์หรือไม่

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

ฉันสามารถหยุด Polling โดยสมบูรณ์หลังเปิดใช้ Webhook ได้หรือไม่

อาจทำได้ หากคุณสมบัติการกู้คืนของผู้ให้บริการและข้อกำหนดทางธุรกิจของคุณยอมรับได้ สำหรับระเบียนการจัดส่งที่สำคัญต่อการดำเนินงาน ควรมีวิธีตรวจสอบความสอดคล้องไว้ การตรวจสอบนั้นอาจเป็นแบบเจาะจงแทนการ Polling การจัดส่งทุกรายการอย่างต่อเนื่อง

จะเกิดอะไรขึ้นหาก Endpoint Webhook ของฉันออฟไลน์

การกู้คืนขึ้นอยู่กับนโยบายการลองส่งซ้ำที่ผู้ส่งระบุไว้ อย่าสมมติว่าการลองส่งซ้ำจะดำเนินต่อไปไม่สิ้นสุด หลังจากกู้คืน Endpoint แล้ว ให้ตรวจสอบการส่งที่ล้มเหลว ใช้เครื่องมือส่งซ้ำที่รองรับ และตรวจสอบการจัดส่งที่ได้รับผลกระทบผ่าน API เมื่อมีให้ใช้งาน

Webhook ทุกเหตุการณ์ควรกระตุ้นการแจ้งเตือนลูกค้าหรือไม่

ไม่ควร เหตุการณ์อาจเป็นข้อมูลซ้ำ จุดตรวจสอบในอดีต หรือการอัปเดตที่ไม่เปลี่ยนสถานะที่แสดงต่อลูกค้า ให้กระตุ้นการแจ้งเตือนจากการเปลี่ยนแปลงทางธุรกิจที่ผ่านการกำจัดข้อมูลซ้ำแล้ว พร้อมกฎสำหรับข้อยกเว้นและการแก้ไข

การตอบกลับ HTTP สำเร็จหมายความว่าการอัปเดตการจัดส่งเสร็จสมบูรณ์หรือไม่

ไม่จำเป็น ในการออกแบบแบบ Asynchronous หมายความว่าตัวรับยอมรับเหตุการณ์ภายใต้สัญญาที่ตกลงกันไว้ ให้ติดตามการเสร็จสิ้นของการประมวลผลและผลลัพธ์ของการแจ้งเตือนภายหลังแยกกัน เพื่อไม่ให้คำขอที่ยอมรับแล้วบดบัง Workflow ที่ล้มเหลว

แหล่งข้อมูล

• RFC 9110: HTTP Semantics — ความหมายของการตอบกลับ HTTP รวมถึงการยอมรับเพื่อประมวลผลและ Retry-After
• RFC 2104: HMAC—Keyed-Hashing for Message Authentication — โครงสร้าง HMAC ที่อ้างถึงในคำแนะนำการตรวจสอบลายเซ็น
• GitHub Docs: แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ Webhook — คำแนะนำทางวิศวกรรมทั่วไปเกี่ยวกับ HTTPS, Secret, การจัดการแบบ Asynchronous และการระบุการส่งข้อมูล กฎเฉพาะบริการของ GitHub ไม่ได้กำหนดพฤติกรรมของผู้ให้บริการด้านการจัดส่ง
• 17TRACK Tracking API — จุดเริ่มต้นอย่างเป็นทางการสำหรับประเมินการผสานรวมการติดตามกับ 17TRACK
• เอกสาร 17TRACK API — ข้อมูลอ้างอิงเฉพาะผู้ให้บริการสำหรับข้อกำหนดการใช้งาน