วิธีติดตามการจัดส่งจากจีนไปยังยุโรปและสหรัฐฯ ด้วย API เดียว

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

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

เริ่มจากเส้นทางการจัดส่ง ไม่ใช่เพียงประเทศปลายทาง

พัสดุที่เดินทางจากจีนไปยังที่อยู่ในยุโรปหรือสหรัฐฯ อาจผ่านบริการรวบรวมพัสดุ เครือข่ายขนส่งระหว่างประเทศ ขั้นตอนศุลกากร และผู้ให้บริการขนส่งปลายทาง บริการจัดส่งบางประเภทแสดงการเคลื่อนย้ายเหล่านี้ภายใต้หมายเลขติดตามเดียว ส่วนบางบริการจะให้ข้อมูลอ้างอิงการจัดส่งแยกต่างหากในช่วงหลังของการเดินทาง

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

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

• สำหรับฝ่ายปฏิบัติการ: ระบุจุดที่ช่องว่างในการติดตามทำให้เกิดงานด้วยตนเองหรือต้องติดต่อกับลูกค้า
• สำหรับฝ่ายวิศวกรรม: ระบุระบบที่สร้างการจัดส่งและระบบที่ต้องรับข้อมูลอัปเดต
• สำหรับฝ่ายจัดซื้อ: ตรวจสอบการรองรับผู้ให้บริการขนส่งและบริการเฉพาะในรายการเส้นทางนั้น

Tracking API เดียวควรทำอะไรได้บ้าง และทำอะไรไม่ได้บ้าง

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

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

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

สร้างการผสานรวมโดยใช้ระเบียนระดับพัสดุเป็นศูนย์กลาง

1. แยกคำสั่งซื้อ การจัดส่ง และตัวระบุการติดตาม

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

โมเดลภายในที่ใช้งานได้จริงควรประกอบด้วย:

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

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

2. ลงทะเบียนพัสดุจากเหตุการณ์ทางธุรกิจที่เชื่อถือได้

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

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

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

3. ออกแบบการส่งข้อมูลอัปเดตก่อนเชื่อมต่อการแจ้งเตือนลูกค้า

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

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

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

4. ทำให้สถานะเป็นมาตรฐานโดยไม่สูญเสียความหมาย

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

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

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

จัดการการส่งต่อระหว่างประเทศอย่างชัดเจน

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

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

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

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

บทบาทของ 17TRACK ในเวิร์กโฟลว์นี้

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

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

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

ดำเนินโครงการนำร่องตามเส้นทางก่อนเปิดใช้งานจริง

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

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

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

ตรวจสอบความใหม่ของข้อมูลแยกจากความพร้อมใช้งานของ API

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

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

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

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

FAQ

API เดียวสามารถติดตามทั้งผู้ให้บริการขนส่งต้นทางในจีนและผู้ให้บริการขนส่งปลายทางได้หรือไม่?

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

เหตุใดการติดตามจึงหยุดอัปเดตหลังพัสดุออกจากจีน?

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

แอปพลิเคชันควรใช้ webhooks หรือ polling?

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

Tracking API สามารถรับประกันวันที่จัดส่งหรือการผ่านพิธีการศุลกากรได้หรือไม่?

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

ควรตรวจสอบอะไรบ้างก่อนเลือกแผน API?

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

แหล่งข้อมูล

• 17TRACK Tracking API — ข้อมูลอ้างอิงผลิตภัณฑ์อย่างเป็นทางการสำหรับบริการ Tracking API
• 17TRACK API documentation — ข้อมูลอ้างอิงทางเทคนิคอย่างเป็นทางการสำหรับการใช้งานการผสานรวม โปรดยืนยันรูปแบบคำขอที่แน่นอน เวิร์กโฟลว์ที่รองรับ และขีดจำกัดจากที่นี่ก่อนเริ่มพัฒนา