วิธีเลือก API ติดตามการจัดส่งสำหรับอีคอมเมิร์ซข้ามพรมแดนในบราซิล
เลือก API ติดตามการจัดส่งสำหรับอีคอมเมิร์ซข้ามพรมแดนในบราซิล โดยทดสอบเส้นทางการจัดส่งจริง การส่งต่อจากระหว่างประเทศสู่ภายในประเทศ เหตุการณ์ที่เกี่ยวข้องกับศุลกากร และกรณีการจัดส่งผิดพลาดของคุณเอง ไม่ใช่เปรียบเทียบเพียงจำนวนผู้ให้บริการขนส่งที่ระบุไว้โดยรวม API ที่เหมาะสมควรรักษารายละเอียดการจัดส่งที่เป็นประโยชน์ เชื่อมต่อกับระบบของคุณได้อย่างน่าเชื่อถือ และรองรับข้อความถึงลูกค้าภาษาโปรตุเกสที่ถูกต้อง โดยไม่เปลี่ยนข้อมูลการติดตามที่ไม่สมบูรณ์ให้กลายเป็นคำรับรองว่าจะจัดส่งได้
สำหรับหัวหน้าฝ่ายปฏิบัติการอีคอมเมิร์ซและทีมวิศวกรรม การตัดสินใจซื้อท้ายที่สุดเป็นเรื่องของการปฏิบัติงาน: การเชื่อมต่อนี้สามารถอธิบายได้หรือไม่ว่าคำสั่งซื้ออยู่ที่ใด ระบุได้หรือไม่ว่าใครควรดำเนินการต่อ และช่วยให้ฝ่ายสนับสนุนลูกค้าไม่ต้องทำงานกับข้อมูลที่ล้าสมัยหรือทำให้เข้าใจผิดหรือไม่ ใช้กรอบการทำงานต่อไปนี้เพื่อเปลี่ยนข้อกำหนดเหล่านั้นให้เป็นรายชื่อผู้ให้บริการที่คัดเลือกได้จริงและการทดสอบแนวคิด
เริ่มจากเส้นทางการจัดส่งในบราซิลของคุณ ไม่ใช่ไดเรกทอรีผู้ให้บริการขนส่งของผู้ให้บริการ API
รายการผู้ให้บริการขนส่งเป็นเพียงจุดเริ่มต้น ไม่ใช่หลักฐานว่า API จะติดตามทุกบริการที่คุณซื้อจากผู้ให้บริการรายนั้นได้ การจัดส่งข้ามพรมแดนอาจเกี่ยวข้องกับผู้ให้บริการต้นทาง พันธมิตรด้านโลจิสติกส์ระหว่างประเทศ และผู้ให้บริการจัดส่งภายในประเทศ ความต่อเนื่องของการติดตามขึ้นอยู่กับว่าเหตุการณ์และตัวระบุใดมีอยู่ตลอดห่วงโซ่เฉพาะนั้น
ก่อนติดต่อผู้ให้บริการ ให้จัดทำรายการเส้นทางโดยใช้การจัดส่งล่าสุด บันทึกประเทศต้นทาง บริการจัดส่ง ผู้ให้บริการโลจิสติกส์ระหว่างประเทศ ผู้ให้บริการจัดส่งในบราซิลเมื่อทราบ และหมายเลขติดตามที่มีในแต่ละขั้นตอน รวมทั้งเส้นทางหลักและเส้นทางปริมาณน้อยที่สร้างคำร้องขอความช่วยเหลือเป็นประจำ
- แยกเส้นทางไปรษณีย์และด่วน อย่าสันนิษฐานว่าความสำเร็จของเส้นทางหนึ่งพิสูจน์ความพร้อมของอีกเส้นทาง
- บันทึกการเปลี่ยนแปลงตัวระบุ ตรวจสอบว่าการจัดส่งใช้หมายเลขติดตามเดียวตลอดเส้นทาง หรือได้รับหมายเลขใหม่หลังการส่งต่อ
- รวมปลายทางและผลลัพธ์ที่มีความยุ่งยาก ทดสอบการจัดส่งล่าช้า ความพยายามจัดส่งไม่สำเร็จ การส่งคืน และประวัติการติดตามที่ไม่สมบูรณ์ ไม่ใช่เฉพาะการจัดส่งที่สำเร็จ
- ระบุเจ้าของธุรกิจ ฝ่ายปฏิบัติการควรตรวจสอบประโยชน์ของเหตุการณ์ ฝ่ายวิศวกรรมควรตรวจสอบพฤติกรรมการเชื่อมต่อ และฝ่ายสนับสนุนควรตรวจสอบคำอธิบายสำหรับลูกค้า
กฎการคัดเลือกข้อแรกควรเรียบง่าย: ผู้ให้บริการต้องแสดงให้เห็นว่าสามารถติดตามเส้นทางสำคัญของคุณได้อย่างมีประโยชน์ ความครอบคลุมที่กว้างในที่อื่นไม่สามารถชดเชยการขาดการส่งต่อบนเส้นทางที่ลูกค้าของคุณใช้งานได้
กำหนดว่าเหตุการณ์การติดตามที่ใช้งานได้ต้องมีอะไรบ้าง
สถานะมาตรฐาน เช่น “อยู่ระหว่างการขนส่ง” ช่วยในการรายงาน แต่แทบไม่เพียงพอสำหรับการสนับสนุนการจัดส่งข้ามพรมแดน ขอชุดข้อมูลตัวอย่างและตรวจสอบว่า API แสดงเหตุการณ์พื้นฐานอย่างไร คุณต้องแยกแยะการเคลื่อนย้ายใหม่จริงจากคำอธิบายที่แปลแล้ว เหตุการณ์ซ้ำ หรือการอัปเดตที่มาถึงล่าช้า
| ข้อมูลที่ต้องประเมิน | เหตุผลที่สำคัญ | สิ่งที่ต้องทดสอบ |
|---|---|---|
| คำอธิบายเหตุการณ์ต้นฉบับ | รักษารายละเอียดที่สถานะกว้างอาจละไว้ | ฝ่ายสนับสนุนสามารถเรียกดูถ้อยคำของผู้ให้บริการขนส่งพร้อมสถานะมาตรฐานได้หรือไม่ |
| เวลาของเหตุการณ์และการจัดการเขตเวลา | ช่วยป้องกันลำดับเวลาที่ไม่ถูกต้องและการคำนวณความล่าช้าที่ทำให้เข้าใจผิด | ระบบแสดงออฟเซ็ตที่หายไป เหตุการณ์ล่าช้า และเหตุการณ์จากประเทศต่าง ๆ อย่างไร |
| ตัวระบุผู้ให้บริการขนส่งและการติดตาม | เชื่อมโยงการเคลื่อนย้ายระหว่างประเทศกับการจัดส่งภายในประเทศ | สามารถเชื่อมโยงหมายเลขที่เกี่ยวข้องโดยไม่สร้างการจัดส่งซ้ำสำหรับลูกค้าได้หรือไม่ |
| ข้อมูลสถานที่ | ให้บริบทเมื่อแหล่งข้อมูลมีข้อมูลดังกล่าว | การเชื่อมต่อแยกแยะสถานที่ที่มีการรายงานจากข้อมูลที่หายไปหรืออนุมานขึ้นได้หรือไม่ |
| รายละเอียดข้อยกเว้น | รองรับการตอบสนองด้านปฏิบัติการที่เหมาะสม | แอปพลิเคชันของคุณแยกแยะความพยายามจัดส่งจากปัญหาที่เกี่ยวข้องกับศุลกากรได้หรือไม่ |
อย่ากำหนดให้ทุกเหตุการณ์ต้องมีทุกฟิลด์ แหล่งข้อมูลต้นทางอาจละเว้นข้อมูลบางอย่าง แต่ควรกำหนดให้มีการแยกแยะอย่างชัดเจนระหว่างข้อเท็จจริงที่รายงาน การตีความของผู้ให้บริการ และข้อมูลที่ไม่พร้อมใช้งาน
มองเห็นข้อมูลศุลกากรในฐานะข้อมูล ไม่ใช่อำนาจอนุมัติพิธีการศุลกากร
สำหรับการจัดส่งไปบราซิล การติดตามที่เกี่ยวข้องกับศุลกากรควรมีการทดสอบการยอมรับเฉพาะของตนเอง ข้อยกเว้นทั่วไปอาจทำให้ฝ่ายสนับสนุนไม่สามารถบอกได้ว่าการจัดส่งกำลังอยู่ระหว่างดำเนินการ ข้อมูลใดขาดหาย หรือมีการรายงานว่าผู้รับต้องดำเนินการหรือไม่
ประเมินว่า API ได้รับข้อมูลใดจากผู้ให้บริการขนส่งหรือพันธมิตรด้านโลจิสติกส์จริง อย่าสันนิษฐานว่าการเชื่อมต่อการติดตามสามารถคำนวณค่าธรรมเนียมนำเข้า ยื่นเอกสารผ่านพิธีการ ยืนยันการชำระเงิน หรือปล่อยพัสดุได้ ความสามารถและความรับผิดชอบเหล่านี้แยกต่างหากและต้องตรวจสอบแยกกัน
- ตรวจสอบว่าเหตุการณ์ที่เกี่ยวข้องกับศุลกากรยังคงคำอธิบายต้นฉบับไว้หรือไม่
- ตรวจสอบว่า “ต้องดำเนินการ” มีการรายงานอย่างชัดเจน หรืออนุมานจากสถานะทั่วไป
- ระบุว่าช่องทางอย่างเป็นทางการใดของผู้ให้บริการขนส่งหรือโลจิสติกส์ควรยืนยันขั้นตอนถัดไป
- ป้องกันไม่ให้ข้อความอัตโนมัติสร้างจำนวนเงินชำระ กำหนดเวลา หรือเอกสารที่ต้องใช้ขึ้นเอง
สำหรับการจัดส่งที่ดำเนินการโดย Correios ให้ใช้เว็บไซต์อย่างเป็นทางการเป็นจุดเริ่มต้นในการตรวจสอบขั้นตอนสำหรับผู้รับ สำหรับรูปแบบการจัดส่งอื่น ให้ยืนยันช่องทางอย่างเป็นทางการที่เหมาะสมกับผู้ให้บริการโลจิสติกส์ตามสัญญา การแจ้งเตือนการติดตามควรอธิบายสถานการณ์ที่มีการรายงานและนำลูกค้าไปยังช่องทางที่ปลอดภัย ไม่ใช่นำเสนอคำสั่งที่ยังไม่ได้ตรวจสอบว่าเป็นข้อกำหนดอย่างเป็นทางการ
ทดสอบความน่าเชื่อถือของการเชื่อมต่อนอกเหนือจากกรณีที่ราบรื่น
คำขอ API ที่สำเร็จไม่ได้พิสูจน์ว่าการจัดส่งจะยังคงซิงโครไนซ์ตลอดเส้นทาง ขอให้ผู้ให้บริการอธิบายการลงทะเบียน การเรียกดูการอัปเดต การส่งเหตุการณ์ การหมดอายุของการติดตาม และการกู้คืนหลังระบบหยุดทำงาน ตรวจสอบคำตอบกับเอกสารและทดสอบพฤติกรรมก่อนตัดสินใจ
การส่งและการกู้คืน Webhook
หากผู้ให้บริการมี webhook ให้ยืนยันการตรวจสอบสิทธิ์ พฤติกรรมการลองใหม่ ระยะเวลาที่คาดว่าจะหมดเวลา และกลไกการเล่นซ้ำหรือกู้คืน ออกแบบตัวรับให้รองรับการส่งซ้ำและเหตุการณ์ที่มาถึงไม่เรียงลำดับ เว้นแต่ผู้ให้บริการจะรับประกันเป็นอย่างอื่นอย่างชัดเจน ตอบรับการรับข้อมูลโดยเร็ว จัดคิวการประมวลผล และหลีกเลี่ยงการส่งข้อความถึงลูกค้าโดยตรงจาก payload ขาเข้าที่ยังไม่ได้ตรวจสอบ
ถามว่าจะเกิดอะไรขึ้นเมื่อ endpoint ของคุณไม่พร้อมใช้งาน ทีมของคุณต้องมีวิธีที่จัดทำเป็นเอกสารเพื่อกระทบยอดการอัปเดตที่หายไป ไม่ว่าจะผ่าน endpoint สำหรับเรียกดู กระบวนการเล่นซ้ำ หรือวิธีกู้คืนอื่นที่รองรับ ยืนยันให้แน่ใจว่าวิธีที่เลือกเหมาะกับสถานการณ์ระบบหยุดทำงานที่คาดไว้
การระบุผู้ให้บริการขนส่งและการลงทะเบียนการจัดส่ง
ทดสอบหมายเลขติดตามที่กำกวม แทนที่จะสันนิษฐานว่าการตรวจจับอัตโนมัติจะระบุผู้ให้บริการที่ต้องการได้เสมอ เมื่อรองรับ การระบุตัวระบุผู้ให้บริการขนส่งที่ทราบอาจช่วยลดความกำกวมได้ ทดสอบการลงทะเบียนซ้ำ หมายเลขไม่ถูกต้อง การสแกนครั้งแรกล่าช้า และการจัดส่งที่ได้รับตัวระบุที่สองด้วย
ความใหม่ของข้อมูลและการสังเกตการณ์
แยกเวลาที่เกิดเหตุการณ์จากผู้ให้บริการขนส่งออกจากเวลาที่ระบบของคุณได้รับข้อมูล วัดช่องว่างเทียบกับข้อมูลอ้างอิงที่จัดทำเป็นเอกสาร โดยตระหนักว่าหน้าติดตามสาธารณะของผู้ให้บริการขนส่งเองอาจอัปเดตล่าช้าหรือแตกต่างจากช่องทางข้อมูลอื่น ถามว่าผู้ให้บริการจัดการการติดตามที่หยุดนิ่งและความล้มเหลวชั่วคราวของแหล่งข้อมูลอย่างไร อย่าตีความทุกช่วงเวลาที่ไม่มีความเคลื่อนไหวว่าเป็นพัสดุสูญหาย
สร้างข้อความภาษาโปรตุเกสโดยเน้นการดำเนินการถัดไปที่เป็นประโยชน์
การแปลภาษาโปรตุเกสไม่ได้มีเพียงการแปลชื่อสถานะ ลูกค้าต้องรู้ว่าเกิดอะไรขึ้น จำเป็นต้องดำเนินการหรือไม่ และจะขอความช่วยเหลือที่เชื่อถือได้จากที่ใด เจ้าหน้าที่สนับสนุนอาจต้องใช้คำอธิบายต้นฉบับของผู้ให้บริการขนส่งเพื่อตรวจสอบเหตุการณ์ที่ผิดปกติ
แยกสามชั้นให้ชัดเจน: เหตุการณ์จากแหล่งข้อมูล หมวดหมู่การปฏิบัติงานภายใน และข้อความสำหรับลูกค้า ตัวอย่างเช่น เหตุการณ์ศุลกากรที่กำกวมไม่ควรถูกเปลี่ยนเป็นคำเรียกเก็บเงินโดยอัตโนมัติ การสแกนเมื่อมาถึงไม่ควรถูกเปลี่ยนเป็นการแจ้งเตือน “กำลังนำจ่าย”
กำหนดกฎระงับการแจ้งเตือนสำหรับเหตุการณ์ซ้ำ เหตุการณ์เก่า และการสแกนระหว่างทางที่มีมูลค่าต่ำ หากแสดงเวลาประมาณการจัดส่ง ให้ตรวจสอบแหล่งที่มาและความหมาย คำรับรองของผู้ค้า ค่าประมาณจากผู้ให้บริการขนส่ง และการคาดการณ์ที่ผู้ให้บริการสร้างขึ้นเป็นคนละสิ่งกัน และไม่ควรนำเสนอแทนกัน
ตรวจสอบความเป็นส่วนตัว ความปลอดภัย และเงื่อนไขทางการค้าร่วมกัน
จัดทำแผนผังข้อมูลที่การเชื่อมต่อของคุณจะส่งก่อนประเมินเงื่อนไขสัญญา บันทึกการติดตามอาจเชื่อมโยงกับคำสั่งซื้อของลูกค้า ดังนั้นให้ลดข้อมูลส่วนบุคคลที่ไม่จำเป็นและจำกัดการเข้าถึงข้อมูลการจัดส่ง อย่าส่งหมายเลขประจำตัวผู้เสียภาษี ที่อยู่ หรือหมายเลขโทรศัพท์ของลูกค้าเพียงเพราะ payload อนุญาตให้มีฟิลด์เพิ่มเติม
สำหรับการประมวลผลข้อมูลส่วนบุคคลที่เกี่ยวข้องกับบราซิล ให้ทีมความเป็นส่วนตัวหรือกฎหมายมีส่วนร่วมในการประเมินภาระหน้าที่ภายใต้ LGPD หน่วยงานคุ้มครองข้อมูลของบราซิล ANPDเป็นแหล่งอ้างอิงอย่างเป็นทางการ ตรวจสอบบทบาทในการประมวลผล การเก็บรักษา การลบ ผู้ประมวลผลช่วง การโอนข้อมูลระหว่างประเทศ และขั้นตอนจัดการเหตุการณ์ตามความเหมาะสมกับข้อตกลงของคุณ คำแถลงด้านความปลอดภัยทั่วไปของผู้จำหน่ายไม่ใช่สิ่งทดแทนการประเมินดังกล่าว
ขอกรณีเชิงพาณิชย์ที่จัดทำเป็นลายลักษณ์อักษรโดยอิงจากปริมาณการจัดส่งและวงจรชีวิตของคุณเอง ยืนยันสิ่งที่คิดค่าบริการ: การลงทะเบียน การจัดส่งที่ติดตาม คำขอ API การอัปเดต หรือหน่วยอื่น ถามว่าการลงทะเบียนซ้ำ การจัดส่งระยะยาว การติดตามซ้ำ ปริมาณเกิน การสนับสนุน และการเข้าถึงประวัติมีผลต่อใบเสนอราคาอย่างไร สิ่งเหล่านี้เป็นคำถามที่ต้องตรวจสอบ ไม่ใช่สมมติฐานเกี่ยวกับราคาของผู้ให้บริการรายใด
เปรียบเทียบต้นทุนการดำเนินงานทั้งหมด รวมถึงการบำรุงรักษาด้านวิศวกรรมและการจัดการข้อยกเว้นด้วยตนเอง ราคาต่อหน่วยที่เสนอถูกกว่าไม่ได้หมายความว่าเป็นโซลูชันที่มีต้นทุนต่ำกว่า หากการเชื่อมต่อทำให้เส้นทางที่มีปริมาณสูงสุดของคุณยังต้องพึ่งพาการตรวจสอบด้วยตนเอง
ตำแหน่งของ 17TRACK ในการประเมิน
สำหรับทีมที่ประเมินการเชื่อมต่อการติดตาม ผลิตภัณฑ์ 17TRACK ที่เกี่ยวข้องคือTracking API ใช้เอกสาร API อย่างเป็นทางการเพื่อประเมินการใช้งานที่เสนอ และขอให้ยืนยันผู้ให้บริการขนส่ง บริการ และสถานการณ์การส่งต่อที่เฉพาะเจาะจงสำหรับเส้นทางไปบราซิลของคุณ
ใช้การทดสอบการยอมรับแบบเดียวกับที่อธิบายไว้ที่นี่ อย่าถือว่าผลการติดตามสำหรับผู้บริโภคเป็นหลักฐานเกี่ยวกับพฤติกรรมการส่งข้อมูลของ API ความพร้อมใช้งานตามสัญญา หรือฟิลด์ข้อมูลใดโดยเฉพาะ ยืนยันการตอบกลับของ API ข้อกำหนดการเชื่อมต่อ เงื่อนไขทางการค้า และข้อตกลงการสนับสนุนโดยตรง
การเชื่อมต่อผู้ให้บริการขนส่งหลายรายควรได้รับการประเมินเมื่อเส้นทางของคุณเกี่ยวข้องกับผู้ให้บริการโลจิสติกส์หลายรายและทีมต้องการอินเทอร์เฟซร่วม การเชื่อมต่อโดยตรงกับผู้ให้บริการขนส่งอาจเพียงพอเมื่อบริการตามสัญญารายเดียวมีสัดส่วนหลักและตรงตามข้อกำหนดข้อมูลของคุณ ทั้งสองสถาปัตยกรรมไม่ได้ขจัดความจำเป็นในการทดสอบประวัติการจัดส่งจริง
ดำเนินการทดสอบแนวคิดด้วยเกณฑ์อนุมัติการซื้อที่ชัดเจน
ใช้การจัดส่งในอดีตเพื่อตรวจสอบเส้นทางที่เสร็จสมบูรณ์ และใช้การจัดส่งจริงเพื่อทดสอบการส่งอัปเดต ประวัติการติดตามเพียงอย่างเดียวไม่สามารถแสดงให้เห็นว่าเหตุการณ์ใหม่จะมาถึงระบบของคุณเร็วเพียงใด ขออนุญาตเมื่อจำเป็นและหลีกเลี่ยงการแบ่งปันข้อมูลลูกค้าที่ไม่จำเป็น
- เลือกตัวอย่างที่เป็นตัวแทน ครอบคลุมต้นทาง บริการ รูปแบบการจัดส่งภายในประเทศ และประเภทข้อยกเว้นที่สำคัญ
- กำหนดข้อมูลอ้างอิงสำหรับการจัดส่งแต่ละรายการ บันทึกประวัติผู้ให้บริการขนส่งที่เกี่ยวข้องและการเปลี่ยนแปลงตัวระบุที่ทราบ จัดทำเอกสารความไม่ตรงกันแทนการเลือกผลลัพธ์ที่ดีกว่าโดยไม่แจ้ง
- วัดผลระดับเส้นทาง ประเมินความสำเร็จในการลงทะเบียน ความพร้อมใช้งานของเหตุการณ์ที่เกี่ยวข้อง ความต่อเนื่องของการส่งต่อ และความล่าช้าในการอัปเดตที่สังเกตได้ ทำให้ตัวหารและกรณีที่หายไปมองเห็นได้
- ทดสอบการจัดการความล้มเหลว ตัดการทำงานของตัวรับ webhook ส่งข้อมูลซ้ำ และทดสอบการกู้คืนโดยไม่สร้างการแจ้งเตือนลูกค้าซ้ำ
- ตรวจสอบข้อความร่วมกับฝ่ายสนับสนุน ถามเจ้าหน้าที่ว่าผลลัพธ์อธิบายการจัดส่งและระบุการดำเนินการถัดไปที่มีเหตุผลรองรับหรือไม่
- อนุมัติเจ้าของงานและต้นทุน มอบหมายความรับผิดชอบต่อความล้มเหลวของการเชื่อมต่อ การประสานงานกับผู้ให้บริการขนส่ง ข้อความถึงลูกค้า และการตรวจสอบใบแจ้งหนี้
กำหนดเกณฑ์การยอมรับก่อนตรวจสอบผลลัพธ์ โดยอิงจากความต้องการทางธุรกิจของคุณ ไม่ใช่เกณฑ์สากลตามอำเภอใจ ให้ความครอบคลุมเส้นทางที่จำเป็น การเชื่อมต่อที่ปลอดภัย และการกู้คืนจากการอัปเดตที่พลาดเป็นเกณฑ์อนุมัติการซื้อ ใช้ฟีเจอร์รองเพื่อแยกความแตกต่างระหว่างผู้ให้บริการหลังผ่านเกณฑ์เหล่านั้นแล้ว
เลือก API ที่ทำให้เส้นทางสำคัญไปบราซิลของคุณเข้าใจได้และกู้คืนได้จริง หากการส่งต่อหรือข้อยกเว้นที่สำคัญยังไม่ได้รับการยืนยัน ให้แก้ไขด้วยการทดสอบเพิ่มเติมหรือข้อตกลงการใช้งานเป็นลายลักษณ์อักษรก่อนขยายการเปิดใช้งาน
คำถามที่พบบ่อย
การรองรับ Correios เพียงพอสำหรับการจัดส่งที่เข้าบราซิลหรือไม่
ไม่จำเป็น ขึ้นอยู่กับเส้นทางตามสัญญาและรูปแบบการจัดส่งปลายทางของคุณ ทดสอบช่วงระหว่างประเทศ การเปลี่ยนแปลงตัวระบุ และช่วงภายในประเทศร่วมกัน รายการของผู้ให้บริการรายหนึ่งไม่ได้ยืนยันการมองเห็นตลอดเส้นทางทั้งหมด
API ติดตามสามารถแก้ไขความล่าช้าทางศุลกากรได้หรือไม่
การติดตามช่วยแสดงเหตุการณ์ที่มีการรายงานและส่งต่อปัญหาไปยังบุคคลที่เหมาะสมได้ แต่ไม่ได้ให้อำนาจในการยื่นเอกสาร เรียกเก็บเงินนำเข้า หรือปล่อยสินค้าโดยตัวมันเอง หากกระบวนการของคุณต้องใช้ฟังก์ชันเหล่านี้ ให้ตรวจสอบแยกต่างหาก
ควรใช้ webhook หรือการเรียกดูเป็นระยะ
เมื่อรองรับ webhook สามารถลดความจำเป็นในการส่งคำขอซ้ำได้ แต่ยังต้องมีการตรวจสอบสิทธิ์ การจัดการข้อมูลซ้ำ และแผนการกู้คืน การเรียกดูเป็นระยะอาจใช้เป็นวิธีหลักในการดึงข้อมูลหรือเป็นกลไกกระทบยอด ขึ้นอยู่กับการออกแบบและข้อจำกัดที่ผู้ให้บริการรองรับ
ควรทำอย่างไรเมื่อการติดตามหยุดอัปเดต
แยกปัญหาการเชื่อมต่อออกจากการจัดส่งที่ไม่มีการเคลื่อนย้ายใหม่ที่มีการรายงาน ตรวจสอบสุขภาพการรับข้อมูลและแหล่งข้อมูลอย่างเป็นทางการ จากนั้นใช้นโยบายส่งต่อเฉพาะเส้นทาง อย่าติดป้ายว่าการจัดส่งสูญหายหรือรับรองวันจัดส่งใหม่โดยอัตโนมัติ
API ติดตามแทนที่ระบบจัดการคำสั่งซื้อของเราหรือไม่
ไม่ ให้มองการติดตามเป็นข้อมูลนำเข้าด้านการจัดส่ง ระบบจัดการคำสั่งซื้อและกระบวนการสนับสนุนของคุณยังคงรับผิดชอบตัวตนของคำสั่งซื้อ กฎการสื่อสารกับลูกค้า การคืนเงิน การเปลี่ยนสินค้า และการตัดสินใจส่งต่อ
แหล่งข้อมูล
- 17TRACK Tracking API — แหล่งอ้างอิงผลิตภัณฑ์อย่างเป็นทางการสำหรับประเมินการเชื่อมต่อ API
- เอกสาร 17TRACK API — แหล่งอ้างอิงทางเทคนิคสำหรับตรวจสอบข้อกำหนดการใช้งานและพฤติกรรมที่รองรับ
- Correios — จุดเริ่มต้นอย่างเป็นทางการสำหรับข้อมูลผู้ให้บริการขนส่งและบริการสำหรับผู้รับ
- Autoridade Nacional de Proteção de Dados — แหล่งอ้างอิงอย่างเป็นทางการของหน่วยงานคุ้มครองข้อมูลบราซิลสำหรับการทบทวนความเป็นส่วนตัว
