วิธีรวมการติดตามการจัดส่งทั่วออสเตรเลียและนิวซีแลนด์ด้วย API เดียว
เพื่อรวมการติดตามพัสดุทั่วออสเตรเลียและนิวซีแลนด์เข้าด้วยกันผ่าน API เดียว ให้เชื่อมต่อระบบคำสั่งซื้อหรือระบบจัดการคำสั่งซื้อของคุณกับบริการติดตามที่รองรับผู้ให้บริการขนส่งหลายราย ลงทะเบียนพัสดุแต่ละรายการด้วยข้อมูลระบุตัวตนของผู้ให้บริการขนส่งที่ถูกต้อง และแปลงการอัปเดตการติดตามที่เข้ามาให้เป็นรูปแบบเหตุการณ์ภายในที่สอดคล้องกัน การผสานรวมควรรักษารายละเอียดเฉพาะของผู้ให้บริการขนส่งไว้ พร้อมมอบประสบการณ์การติดตามเดียวกันแก่ทีมปฏิบัติการและลูกค้าของคุณสำหรับการจัดส่งภายในประเทศและระหว่างออสเตรเลียกับนิวซีแลนด์
สำหรับนักพัฒนา ผู้ดำเนินงานอีคอมเมิร์ซ และทีมโลจิสติกส์ ความท้าทายหลักไม่ใช่การส่งคำขอ API ครั้งแรก แต่คือการรักษาข้อมูลระบุตัวตนของพัสดุ สถานะการจัดส่ง การส่งต่อระหว่างผู้ให้บริการขนส่ง และการแจ้งเตือนลูกค้าให้สอดคล้องกัน เมื่อผู้ให้บริการขนส่งแต่ละรายอธิบายการเดินทางเดียวกันแตกต่างกัน คู่มือนี้อธิบายวิธีออกแบบการผสานรวมดังกล่าว วิธีประเมิน API สำหรับการติดตาม และวิธีทดสอบก่อนนำไปใช้งานจริง
กำหนดสิ่งที่ API เดียวต้องรวมให้เป็นหนึ่ง
API ที่ใช้ร่วมกันช่วยให้แอปพลิเคชันของคุณมีจุดเชื่อมต่อร่วมกัน แต่ไม่ได้ทำให้ผู้ให้บริการขนส่งทุกรายเผยแพร่ข้อมูลเหมือนกันหรือสแกนพัสดุด้วยความถี่เท่ากัน สถาปัตยกรรมของคุณต้องแยกความแตกต่างระหว่างอินเทอร์เฟซที่สอดคล้องกันกับการมองเห็นข้อมูลอย่างครบถ้วน
เริ่มต้นด้วยรายการพัสดุที่อ้างอิงจากกิจกรรมการจัดส่งจริง แทนที่จะใช้รายชื่อทั่วไปของผู้ให้บริการขนส่งที่ดำเนินงานในประเทศใดประเทศหนึ่ง รวมการจัดส่งภายในประเทศออสเตรเลีย การจัดส่งภายในประเทศนิวซีแลนด์ และการขนส่งข้ามพรมแดนทั้งสองทิศทาง เพิ่มต้นทางระหว่างประเทศอื่น ๆ หากเป็นส่วนหนึ่งของธุรกิจของคุณ
- ผู้ให้บริการขนส่งและบริการ: บันทึกผู้ให้บริการขนส่ง บริการที่ใช้ และพันธมิตรจัดส่งที่ทราบ
- เส้นทาง: แยกต้นทางและปลายทางของพัสดุออกจากตำแหน่งที่สแกนล่าสุด
- ข้อมูลระบุตัวตน: เก็บหมายเลขอ้างอิงคำสั่งซื้อ หมายเลขอ้างอิงการจัดส่ง หมายเลขติดตาม และหมายเลขทดแทนหรือหมายเลขของพันธมิตร หากมี
- วัตถุประสงค์ด้านการปฏิบัติการ: ระบุว่าการอัปเดตรองรับการติดตามของลูกค้า การจัดการข้อยกเว้น การยืนยันการจัดส่ง หรือทั้งสามอย่าง
- รายละเอียดที่จำเป็น: ตัดสินใจว่าสถานะการจัดส่งโดยรวมเพียงพอหรือไม่ หรือเจ้าหน้าที่จำเป็นต้องดูคำอธิบายการสแกน ตำแหน่ง และเวลาเพิ่มเติม
รายการนี้จะกลายเป็นรายการตรวจสอบการยอมรับของคุณ ความครอบคลุมผู้ให้บริการขนส่งโดยรวมของผู้ให้บริการมีประโยชน์สำหรับการคัดเลือกเบื้องต้น แต่การตัดสินใจควรพิจารณาว่าชุดผู้ให้บริการขนส่งและบริการที่คุณใช้งานจริงสามารถส่งคืนข้อมูลการติดตามที่ใช้งานได้หรือไม่
ประเมิน API การติดตามให้สอดคล้องกับประเภทพัสดุของคุณ
17TRACK มี Tracking API จึงเป็นตัวเลือกที่เหมาะสมสำหรับประเมินการผสานรวมผู้ให้บริการขนส่งหลายราย ใช้ เอกสาร API อย่างเป็นทางการ เพื่อตรวจสอบข้อกำหนดการผสานรวมในปัจจุบัน ให้ถือว่าการรองรับผู้ให้บริการขนส่ง ฟิลด์เหตุการณ์ พฤติกรรมการอัปเดต ขีดจำกัดบัญชี และเงื่อนไขทางการค้าเป็นรายการที่ต้องตรวจสอบสำหรับการนำไปใช้งานของคุณ ไม่ใช่สิ่งที่ควรคาดเดาจากประเภทผลิตภัณฑ์
ถามคำถามเชิงปฏิบัติแบบเดียวกันกับ API ทุกตัวที่คุณพิจารณา:
- ระบบสามารถระบุและติดตามผู้ให้บริการขนส่งและบริการต่าง ๆ ในรายการพัสดุของคุณได้หรือไม่
- เมื่อการตรวจจับผู้ให้บริการขนส่งไม่ชัดเจน คุณสามารถระบุตัวระบุผู้ให้บริการขนส่งอย่างชัดเจนได้หรือไม่
- แอปพลิเคชันของคุณรับการอัปเดตอย่างไร และมีกลไกกู้คืนใดหากพลาดการอัปเดต
- รายละเอียดดั้งเดิมของผู้ให้บริการขนส่งใดยังคงมีอยู่ควบคู่กับสถานะที่ทำให้เป็นมาตรฐานแล้ว
- จะเกิดอะไรขึ้นเมื่อหมายเลขติดตามไม่ถูกต้อง ยังไม่เป็นที่รู้จัก หรือเชื่อมโยงกับผู้ให้บริการขนส่งที่เป็นไปได้มากกว่าหนึ่งราย
- มีการกำหนดการใช้งาน การเรียกเก็บเงิน ระยะเวลาการติดตาม และขีดจำกัดการเข้าถึงสำหรับบัญชีของคุณอย่างไร
หลักเกณฑ์การตัดสินใจที่แนะนำ: เลือกจากผลการทดสอบรูปแบบการจัดส่งจริงของคุณที่ประสบความสำเร็จ ไม่ใช่จากจำนวนผู้ให้บริการขนส่งที่ระบุไว้ในหัวข้อประชาสัมพันธ์ การผสานรวมเหมาะสมเมื่อให้ข้อมูลเพียงพอสำหรับสนับสนุนการตัดสินใจด้านการปฏิบัติงาน และแสดงความล้มเหลวได้ชัดเจนเพียงพอที่จะกู้คืนได้
สร้างโมเดลภายในที่รองรับความแตกต่างของผู้ให้บริการขนส่ง
แยกคำสั่งซื้อ พัสดุ และช่วงการติดตามออกจากกัน
อย่าใช้หมายเลขติดตามเป็นคีย์หลักของคำสั่งซื้อ คำสั่งซื้อหนึ่งรายการอาจมีหลายพัสดุ และการเดินทางของพัสดุหนึ่งรายการอาจมีตัวระบุการติดตามมากกว่าหนึ่งรายการ ให้สร้าง ID พัสดุภายในแทน และเชื่อมโยงระเบียนการติดตามเข้ากับ ID ดังกล่าว
โมเดลเชิงปฏิบัติมีสามระดับ ได้แก่ คำสั่งซื้อของลูกค้า พัสดุจริงของคำสั่งซื้อนั้น และช่วงการติดตามที่เชื่อมโยงกับพัสดุแต่ละรายการ พัสดุภายในประเทศอาจต้องใช้ช่วงการติดตามเพียงหนึ่งช่วง ส่วนพัสดุข้ามพรมแดนอาจต้องมีระเบียนที่เชื่อมโยงกันเมื่อผู้ให้บริการขนส่งหรือตัวระบุอื่นเข้ามาเกี่ยวข้อง
กำหนดขอบเขตระเบียนการติดตามด้วยผู้ให้บริการขนส่งควบคู่กับหมายเลขติดตาม และรักษาความสัมพันธ์กับ ID พัสดุของคุณ หากมีหมายเลขของพันธมิตรจัดส่งรายใหม่ปรากฏขึ้น ให้เพิ่มเป็นตัวระบุที่เกี่ยวข้องแทนการเขียนทับหมายเลขเดิม วิธีนี้จะรักษาประวัติที่เจ้าหน้าที่สนับสนุนต้องใช้เมื่อตรวจสอบการส่งต่อพัสดุ
เก็บเหตุการณ์ดิบและเหตุการณ์ที่ทำให้เป็นมาตรฐาน
ใช้คำศัพท์สถานะภายในขนาดเล็กที่ธุรกิจของคุณสามารถนำไปปฏิบัติได้ ตัวอย่างเช่น ก่อนการขนส่ง อยู่ระหว่างการขนส่ง กำลังนำจ่าย พร้อมให้รับ จัดส่งแล้ว ข้อยกเว้น และไม่ทราบ หมวดหมู่เหล่านี้เป็นหมวดหมู่ภายในที่เสนอแนะ ไม่ใช่ข้ออ้างอิงเกี่ยวกับโครงสร้างสถานะของผู้ให้บริการรายใดรายหนึ่ง
จัดเก็บคำอธิบายดั้งเดิมของผู้ให้บริการขนส่งไว้ควบคู่กับสถานะที่แมปแล้ว เหตุการณ์ที่พัสดุถึงจุดรับสินค้าและปัญหาที่อยู่ปลายทางอาจต้องให้ลูกค้าดำเนินการเหมือนกัน แต่ไม่ควรสร้างข้อความเดียวกัน ในทำนองเดียวกัน การสร้างใบจ่าหน้าพัสดุไม่ควรถูกตีความโดยอัตโนมัติว่าเป็นหลักฐานว่าผู้ให้บริการขนส่งรับพัสดุไว้จริงแล้ว
บันทึกการตัดสินใจในการแมปไว้ในการกำหนดค่าที่มีการจัดการเวอร์ชัน เมื่อมีคำอธิบายเหตุการณ์ใหม่ปรากฏขึ้น ให้ส่งเข้าคิวตรวจสอบหากความหมายไม่ชัดเจน สถานะไม่ทราบที่ระบุไว้อย่างชัดเจนปลอดภัยกว่าการกำหนดผลลัพธ์การจัดส่งผิดด้วยความมั่นใจ
แยกเวลาที่เกิดเหตุการณ์ออกจากเวลาที่ได้รับข้อมูล
จัดเก็บเวลาที่เหตุการณ์เกิดขึ้นแยกจากเวลาที่ระบบของคุณได้รับข้อมูล เหตุการณ์การสแกนที่เก่ากว่าอาจมาถึงหลังเหตุการณ์ใหม่กว่า โดยเฉพาะเมื่อการอัปเดตล่าช้าหรือมีการส่งเหตุการณ์ย้อนหลังมาพร้อมกัน
สำหรับออสเตรเลียและนิวซีแลนด์ หลีกเลี่ยงการใช้ส่วนต่างเวลาคงที่เดียวกับพัสดุทุกชิ้น รักษาประทับเวลาและส่วนต่างเวลาจากแหล่งข้อมูลเมื่อมีการระบุไว้ ใช้เขตเวลาที่มีชื่อเหมาะสมสำหรับการแสดงผลเมื่อมีบริบทตำแหน่งที่เชื่อถือได้ และคำนึงถึงความแตกต่างของเวลาออมแสง หากไม่มีเขตเวลาจากแหล่งข้อมูล ให้รักษาความไม่แน่นอนไว้แทนการสร้างการแปลงเป็น UTC ที่แม่นยำขึ้นมาเอง
นำเวิร์กโฟลว์การรับข้อมูลที่เชื่อถือได้มาใช้งาน
- สร้างพัสดุภายในก่อน บันทึกความสัมพันธ์กับคำสั่งซื้อ เส้นทาง การเลือกผู้ให้บริการขนส่ง และตัวระบุการติดตามก่อนลงทะเบียนกับบริการติดตาม
- ส่งการลงทะเบียนการติดตาม ใช้รูปแบบคำขอที่ระบุไว้ในเอกสารของผู้ให้บริการ จัดเก็บการตอบกลับ และแยกการลงทะเบียนที่สำเร็จออกจากการที่เหตุการณ์ของผู้ให้บริการขนส่งพร้อมใช้งานในภายหลัง
- จัดประเภทความล้มเหลว แยกข้อมูลนำเข้าที่ไม่ถูกต้องและปัญหาการยืนยันตัวตนออกจากความล้มเหลวของบริการชั่วคราว ให้ลองใหม่เฉพาะกรณีที่การลองใหม่มีแนวโน้มช่วยได้อย่างสมเหตุสมผล
- รับหรือดึงข้อมูลอัปเดต นำกลไกการส่งข้อมูลที่ API ที่คุณเลือกสนับสนุนมาใช้งาน หากใช้เว็บฮุก ให้ตรวจสอบคำขอขาเข้าด้วยวิธีที่ระบุไว้ในเอกสารของผู้ให้บริการ และประมวลผลเหตุการณ์ที่ยอมรับแล้วผ่านคิวถาวร
- กำจัดข้อมูลซ้ำก่อนใช้การเปลี่ยนแปลง ใช้ตัวระบุเหตุการณ์ของผู้ให้บริการเมื่อมี หรือใช้คีย์ผสมที่ออกแบบอย่างรอบคอบ การส่งข้อมูลซ้ำต้องไม่ทำให้เกิดการแจ้งเตือนลูกค้าซ้ำ
- คำนวณสถานะพัสดุใหม่ ประเมินความหมายและลำดับเวลาของเหตุการณ์ แทนการแทนที่สถานะปัจจุบันด้วยการอัปเดตใดก็ตามที่มาถึงล่าสุด
- ตรวจสอบระเบียนที่ไม่สมบูรณ์ให้สอดคล้องกัน หาก API รองรับการดึงข้อมูล ให้ใช้เพื่อตรวจสอบการอัปเดตที่พลาดหรือระเบียนที่ล้าสมัยภายในขีดจำกัดการใช้งานที่เกี่ยวข้อง
เก็บการยืนยันตัวตนเฉพาะผู้ให้บริการ ชื่อฟิลด์ และการจัดการข้อผิดพลาดไว้ภายในอะแดปเตอร์ ระบบจัดการคำสั่งซื้อของคุณควรใช้โมเดลพัสดุภายในของคุณ แทนการพึ่งพารายละเอียดทุกอย่างจากการตอบกลับของผู้ให้บริการโดยตรง การแยกส่วนนี้ยังทำให้การทดสอบการเปลี่ยนแปลง API ในภายหลังง่ายขึ้น
จัดการเส้นทางข้ามทะเลแทสมันโดยไม่สร้างความแน่นอนขึ้นมาเอง
การติดตามข้ามพรมแดนต้องการบริบทมากกว่าลำดับป้ายกำกับสถานะ แอปพลิเคชันของคุณควรแยกเหตุการณ์ส่งออก เหตุการณ์ที่เกี่ยวข้องกับศุลกากร การส่งต่อระหว่างผู้ให้บริการขนส่ง และเหตุการณ์การจัดส่งขั้นสุดท้าย เมื่อข้อมูลต้นทางรองรับการแยกแยะดังกล่าว
อย่าสรุปว่าพัสดุผ่านพิธีการศุลกากรแล้วจากการสแกนทั่วไปว่าอยู่ระหว่างการขนส่ง ในทำนองเดียวกัน การไม่มีการสแกนล่าสุดไม่ได้ยืนยันว่าศุลกากรกำลังยึดพัสดุไว้ ข้อความที่เป็นประโยชน์ต่อลูกค้าควรระบุเหตุการณ์ล่าสุดที่ยืนยันได้และเวลาของเหตุการณ์นั้น จากนั้นอธิบายการดำเนินการถัดไปที่ทีมของคุณสามารถสนับสนุนได้จริง
แยกต้นทางและปลายทางออกจากตำแหน่งที่สแกน พัสดุที่เดินทางจากออสเตรเลียไปนิวซีแลนด์ไม่ได้กลายเป็นพัสดุภายในประเทศนิวซีแลนด์เพียงเพราะได้รับการสแกนขาเข้า ความแตกต่างนี้มีความสำคัญต่อการรายงานเส้นทางและผู้รับผิดชอบข้อยกเว้น
หากมีพันธมิตรจัดส่งเข้ามาเกี่ยวข้อง ให้เชื่อมโยงระเบียนการติดตามของพันธมิตรเมื่อความสัมพันธ์ดังกล่าวได้รับการสนับสนุนจากข้อมูลพัสดุ บริการติดตาม หรือระเบียนที่ตรวจสอบยืนยันในเชิงปฏิบัติการแล้วเท่านั้น อย่ารวมพัสดุเพียงเพราะตัวระบุดูคล้ายกัน
เปลี่ยนเหตุการณ์การติดตามให้เป็นการอัปเดตที่มีประโยชน์ต่อลูกค้า
หน้าที่แสดงต่อลูกค้าควรตอบคำถามสี่ข้อ ได้แก่ สถานะล่าสุดที่ยืนยันได้คืออะไร เกิดขึ้นเมื่อใด บันทึกไว้ที่ใดหากทราบ และลูกค้าต้องดำเนินการหรือไม่
แยกกฎการแจ้งเตือนออกจากการรับเหตุการณ์ ไม่ใช่ทุกการสแกนที่ควรได้รับอีเมลหรือข้อความ กำหนดการเปลี่ยนแปลงที่มีความหมาย เช่น การเคลื่อนย้ายครั้งแรกที่ยืนยันได้ ความพยายามจัดส่ง ข้อกำหนดในการรับพัสดุ หรือเหตุการณ์จัดส่งสำเร็จ และระงับการแจ้งเตือนซ้ำสำหรับการเปลี่ยนแปลงเดียวกัน
- การติดตามล้าสมัย: ระบุว่าเกิดการอัปเดตครั้งล่าสุดเมื่อใด โดยไม่ถือว่าความเงียบเป็นหลักฐานว่าพัสดุสูญหาย
- การประเมินเวลาจัดส่ง: แยกการประเมินที่ผู้ให้บริการขนส่งระบุออกจากคำมั่นสัญญาของผู้ค้า อย่าสร้างวันที่ขึ้นมาเมื่อไม่มีข้อมูลใดรองรับ
- ข้อยกเว้น: ให้ขั้นตอนถัดไปที่ชัดเจนเมื่อทราบ แทนการแสดงป้ายข้อผิดพลาดที่ไม่มีคำอธิบาย
- ข้อโต้แย้งเกี่ยวกับการจัดส่งสำเร็จ: รักษาเหตุการณ์ต้นทางไว้และส่งกรณีไปยังฝ่ายสนับสนุน สถานะจัดส่งสำเร็จเพียงอย่างเดียวไม่สามารถแก้ไขข้อโต้แย้งของลูกค้าได้ทุกกรณี
ปกป้องหน้าติดตามเช่นเดียวกับข้อมูลรับรอง API หลีกเลี่ยงการเปิดเผยที่อยู่หรือรายละเอียดการติดต่อที่ไม่จำเป็น เก็บข้อมูลรับรองบริการไว้บนเซิร์ฟเวอร์ และใช้การควบคุมการเข้าถึงให้เหมาะสมกับข้อมูลที่แสดง
ดำเนินโครงการนำร่องตามเส้นทางก่อนเปิดใช้งานจริง
ทดสอบการจัดส่งภายในประเทศออสเตรเลีย ภายในประเทศนิวซีแลนด์ จากออสเตรเลียไปนิวซีแลนด์ และจากนิวซีแลนด์ไปออสเตรเลีย เมื่อเส้นทางเหล่านี้เกี่ยวข้องกับธุรกิจของคุณ รวมการจัดส่งทั่วไปและกรณีขอบเขตด้านปฏิบัติการ เช่น คำสั่งซื้อที่แบ่งเป็นหลายรายการ หมายเลขที่ไม่รู้จัก การส่งต่อ ความพยายามจัดส่ง เหตุการณ์การรับพัสดุ การส่งคืน และการสแกนที่มาถึงล่าช้า
ใช้ระเบียนพัสดุจริงโดยมีสิทธิ์ที่เหมาะสมสำหรับการตรวจสอบผู้ให้บริการขนส่ง ใช้เหตุการณ์จำลองเพื่อทดสอบความทนทานของแอปพลิเคชันของคุณเอง แต่อย่าถือว่าผลลัพธ์จำลองเป็นหลักฐานของการรองรับผู้ให้บริการขนส่งจริง
- การตรวจสอบตัวตน: การอัปเดตแต่ละรายการไปถึงพัสดุและคำสั่งซื้อที่ถูกต้อง
- การตรวจสอบลำดับเวลา: เหตุการณ์ที่มาถึงไม่เรียงลำดับจะไม่ย้อนความคืบหน้าการจัดส่งอย่างไม่ถูกต้อง
- การตรวจสอบการกู้คืน: ความล้มเหลวชั่วคราวและการอัปเดตซ้ำจะไม่ทำให้ข้อมูลสูญหายหรือแจ้งเตือนซ้ำ
- การตรวจสอบฝ่ายสนับสนุน: เจ้าหน้าที่สามารถตรวจสอบเหตุการณ์ดั้งเดิมและเข้าใจสถานะที่แสดงต่อลูกค้า
- การตรวจสอบเชิงพาณิชย์: การใช้งานที่คาดการณ์ไว้สอดคล้องกับรูปแบบการเรียกเก็บเงินและขีดจำกัดบัญชีที่ตรวจสอบแล้ว
กำหนดเกณฑ์การยอมรับก่อนประเมินโครงการนำร่อง วัดผลการลงทะเบียน เหตุการณ์ที่แมปไม่ได้ ความล่าช้าในการประมวลผล การแจ้งเตือนซ้ำ และพัสดุที่ล้าสมัยซึ่งยังไม่ได้รับการแก้ไข แยกความล่าช้าของข้อมูลจากผู้ให้บริการขนส่งออกจากความล่าช้าภายในแอปพลิเคชันของคุณ เพื่อให้การแก้ไขไปถึงผู้รับผิดชอบที่ถูกต้อง
การนำไปใช้งานพร้อมแล้วเมื่อทีมของคุณสามารถอธิบายและกู้คืนจากการติดตามที่ไม่สมบูรณ์ได้ ไม่ใช่เพียงแสดงการจัดส่งที่สำเร็จเท่านั้น API เดียวช่วยลดความซับซ้อนของการเชื่อมต่อ ส่วนโมเดลพัสดุ กฎเหตุการณ์ และขั้นตอนการปฏิบัติงานของคุณจะทำให้การเชื่อมต่อนั้นเชื่อถือได้
คำถามที่พบบ่อย
API การติดตามหนึ่งรายการสามารถแทนที่การผสานรวมการจัดส่งของผู้ให้บริการขนส่งได้หรือไม่
ไม่จำเป็น การติดตาม การสร้างใบจ่าหน้า การจองรับพัสดุ การคำนวณอัตราค่าจัดส่ง และเอกสารศุลกากรเป็นฟังก์ชันแยกจากกัน ตรวจสอบขอบเขตของผลิตภัณฑ์ที่เลือก และคงการผสานรวมอื่นไว้เมื่อกระบวนการจัดส่งของคุณต้องใช้
ฉันสามารถลงทะเบียนหมายเลขติดตามก่อนการสแกนครั้งแรกของผู้ให้บริการขนส่งได้หรือไม่
ตรวจสอบกฎการลงทะเบียนของ API ออกแบบแอปพลิเคชันให้แยกการลงทะเบียนหมายเลขติดตามที่ได้รับการยอมรับออกจากการเคลื่อนย้ายจริงที่ได้รับการยืนยัน ระเบียนที่ยังไม่มีเหตุการณ์ไม่ควรถูกแสดงเป็นอยู่ระหว่างการขนส่งโดยอัตโนมัติ
API เดียวจะให้การอัปเดตแบบเรียลไทม์สำหรับผู้ให้บริการขนส่งทุกรายหรือไม่
อย่าคิดเช่นนั้น ความใหม่ของข้อมูลตั้งแต่ต้นทางถึงปลายทางขึ้นอยู่กับเวลาที่ผู้ให้บริการขนส่งเผยแพร่ข้อมูล เวลาที่บริการติดตามได้รับข้อมูล และเวลาที่แอปพลิเคชันของคุณประมวลผลข้อมูล ยืนยันพฤติกรรมการอัปเดตสำหรับชุดผู้ให้บริการขนส่งและบริการที่คุณใช้งาน
ควรทำอย่างไรเมื่อหมายเลขติดตามเปลี่ยนแปลง
เก็บตัวระบุเดิมไว้ และเชื่อมโยงตัวระบุทดแทนหรือของพันธมิตรที่ตรวจสอบแล้วเข้ากับพัสดุภายในรายการเดิม รักษาประวัติทั้งสองชุด และป้องกันไม่ให้ระเบียนซ้ำสร้างการแจ้งเตือนที่ขัดแย้งกัน
17TRACK เหมาะสมกับการผสานรวมนี้หรือไม่
เหมาะสม Tracking API ของ 17TRACK เกี่ยวข้องกับการผสานรวมผู้ให้บริการขนส่งหลายรายที่อธิบายไว้ที่นี่ ประเมินโดยใช้ตัวอย่างพัสดุจากออสเตรเลียและนิวซีแลนด์ของคุณ และยืนยันการรองรับผู้ให้บริการขนส่ง พฤติกรรมทางเทคนิค และเงื่อนไขบัญชีผ่านแหล่งข้อมูล API อย่างเป็นทางการก่อนนำไปใช้งาน
แหล่งข้อมูล
- 17TRACK Tracking API — แหล่งข้อมูลผลิตภัณฑ์อย่างเป็นทางการสำหรับตัวเลือก API ที่กล่าวถึงในคู่มือนี้
- เอกสาร API ของ 17TRACK — เอกสารอ้างอิงทางเทคนิคอย่างเป็นทางการสำหรับตรวจสอบรูปแบบคำขอ ข้อกำหนดการผสานรวม และพฤติกรรมที่รองรับ
