วิธีใช้ Ups Tracking Api: คู่มือการตั้งค่าทีละขั้นตอน
ในการใช้ UPS Tracking API ให้สร้างบัญชี UPS Developer ลงทะเบียนแอปพลิเคชัน รับข้อมูลประจำตัว OAuth 2.0 ขอ access token และส่งคำขอติดตามที่ผ่านการยืนยันตัวตนโดยใช้หมายเลขติดตาม UPS ที่ถูกต้อง ป้ายชื่อบนพอร์ทัล ขั้นตอนการอนุมัติ และข้อกำหนดของ API อาจเปลี่ยนแปลงได้ ดังนั้นควรตรวจสอบคำแนะนำปัจจุบันใน UPS Developer Portal อย่างเป็นทางการก่อนนำการเชื่อมต่อไปใช้งานจริง
คู่มือนี้จัดทำขึ้นสำหรับนักพัฒนาและทีมปฏิบัติการอีคอมเมิร์ซที่ต้องการแสดงสถานะการจัดส่งภายในร้านค้าออนไลน์ ระบบจัดการคำสั่งซื้อ เวิร์กโฟลว์คลังสินค้า เครื่องมือบริการลูกค้า หรือแดชบอร์ดภายใน โดยเน้นลำดับการเชื่อมต่อ การตัดสินใจที่ส่งผลต่อความน่าเชื่อถือ และการตรวจสอบที่ช่วยป้องกันปัญหาการติดตามทั่วไป
UPS Tracking API ทำอะไรได้บ้าง
การเชื่อมต่อ API ช่วยให้ซอฟต์แวร์ร้องขอข้อมูลการจัดส่งจาก UPS แทนการให้พนักงานหรือลูกค้าเปิดหน้าติดตามของผู้ให้บริการขนส่งด้วยตนเอง แอปพลิเคชันของคุณสามารถใช้การตอบกลับเพื่อแสดงสถานะล่าสุดที่ทราบ ระบุเหตุการณ์การจัดส่ง สนับสนุนการตรวจสอบของฝ่ายบริการลูกค้า หรือเรียกใช้เวิร์กโฟลว์ภายใน
API ไม่เหมือนกับหน้าติดตาม หน้าติดตามออกแบบมาให้คนอ่าน ส่วนการตอบกลับของ API เป็นข้อมูลที่มีโครงสร้างซึ่งซอฟต์แวร์ต้องแยกวิเคราะห์ จัดเก็บ และนำเสนอ ระบบของคุณยังคงรับผิดชอบด้านการยืนยันตัวตน การจัดการข้อผิดพลาด การเรียกข้อมูลเป็นระยะหรือการรวบรวมเหตุการณ์ การเก็บรักษาข้อมูล การออกแบบส่วนติดต่อผู้ใช้ และกฎทางธุรกิจที่สร้างขึ้นจากเหตุการณ์การจัดส่ง
ก่อนเริ่มต้น
เตรียมรายการต่อไปนี้ก่อนเปิด developer portal:
- บัญชี UPS Developer หรือประเภทบัญชีที่กระบวนการเริ่มต้นใช้งาน UPS ปัจจุบันกำหนด
- แอปพลิเคชันที่ลงทะเบียนแล้วและข้อมูลประจำตัวที่ออกให้กับแอปพลิเคชันนั้น
- หมายเลขติดตามสำหรับทดสอบหรือวิธีทดสอบอื่นที่ได้รับอนุมัติ หากเอกสารของ UPS ระบุสภาพแวดล้อมหรือขั้นตอนการทดสอบแยกต่างหาก อย่าเริ่มต้นด้วยข้อมูลลูกค้าจริง
- การตัดสินใจที่ชัดเจนว่าระบบใดเป็นเจ้าของระเบียนการจัดส่ง เหตุการณ์การติดตาม และข้อความสถานะที่แสดงต่อลูกค้า
- สถานที่ที่ปลอดภัยสำหรับจัดเก็บข้อมูลประจำตัวไคลเอนต์และ access token ห้ามใส่ข้อมูลลับไว้ในโค้ดเบราว์เซอร์ พื้นที่เก็บโค้ดสาธารณะ ภาพหน้าจอ หรือแอปพลิเคชันมือถือที่ผู้ใช้สามารถตรวจสอบได้
คุณควรตัดสินใจด้วยว่าแอปพลิเคชันต้องการเพียงการติดตามหรือการเชื่อมต่อ UPS ที่ครอบคลุมกว่านั้น การติดตาม การคำนวณราคา การจัดส่ง การตรวจสอบที่อยู่ และบริการเอกสารอาจเป็นผลิตภัณฑ์ที่แตกต่างกัน มีสิทธิ์ รูปแบบคำขอ และข้อกำหนดด้านการปฏิบัติงานแตกต่างกัน
ขั้นตอนที่ 1: เปิด UPS Developer Portal
เริ่มต้นที่ UPS Developer Portal อย่างเป็นทางการ ตรวจสอบแคตตาล็อก API คำแนะนำด้านการยืนยันตัวตน ข้อกำหนดการเริ่มต้นใช้งาน เงื่อนไข และข้อมูลสภาพแวดล้อมปัจจุบัน โดยเฉพาะให้ค้นหาเอกสาร Tracking API แทนการสมมติว่าคำแนะนำสำหรับบริการ UPS อื่นใช้กับการติดตามได้เช่นกัน
พอร์ทัลเป็นแหล่งข้อมูลที่เหมาะสมสำหรับฟิลด์คำขอ ขอบเขตการอนุญาต คำจำกัดความการตอบกลับ ขีดจำกัดอัตราการเรียก รหัสข้อผิดพลาด และรายละเอียดสภาพแวดล้อมล่าสุด ข้อมูลเหล่านี้อาจเปลี่ยนแปลงได้ และตัวอย่างโค้ดจากบุคคลที่สามอาจใช้ส่วนติดต่อ UPS รุ่นเก่าหรือวิธีการยืนยันตัวตนที่ล้าสมัย
ขั้นตอนที่ 2: ลงทะเบียนแอปพลิเคชัน
สร้างแอปพลิเคชันใน developer portal และเลือก UPS API ที่แอปพลิเคชันต้องใช้จริง สำหรับโครงการที่ใช้เฉพาะการติดตาม ให้ขอเฉพาะความสามารถด้านการติดตาม เว้นแต่เวิร์กโฟลว์ของคุณต้องใช้บริการเพิ่มเติม การจำกัดสิทธิ์ช่วยลดความซับซ้อนของการกำหนดค่าและทำให้การแก้ไขปัญหาในภายหลังง่ายขึ้น
บันทึกรหัสประจำตัวและข้อมูลลับของแอปพลิเคชันไว้ในตัวจัดการข้อมูลลับฝั่งเซิร์ฟเวอร์หรือระบบตัวแปรสภาพแวดล้อมที่ได้รับการป้องกัน ปฏิบัติต่อข้อมูลลับเสมือนรหัสผ่าน หากข้อมูลถูกเปิดเผย ให้หมุนเวียนข้อมูลผ่านกระบวนการที่ UPS จัดเตรียมไว้ และตรวจสอบบันทึกการใช้งานที่ไม่ได้รับอนุญาต
หากพอร์ทัลขอข้อมูลบัญชี การเรียกเก็บเงิน ธุรกิจ หรือแอปพลิเคชัน ให้ระบุข้อมูลที่ถูกต้อง หลีกเลี่ยงการสร้างกรณีใช้งานจริงขึ้นมาเองหรือใช้ข้อมูลบัญชีของผู้อื่นเพียงเพื่อทำการทดสอบ การเข้าถึงบริการอาจขึ้นอยู่กับการกำหนดค่าบัญชีและกระบวนการอนุมัติ UPS ปัจจุบัน
ขั้นตอนที่ 3: ใช้การยืนยันตัวตน OAuth 2.0
เอกสารสำหรับนักพัฒนา UPS ปัจจุบันใช้การยืนยันตัวตนแบบ OAuth สำหรับ API เซิร์ฟเวอร์ของคุณจะแลกเปลี่ยนข้อมูลประจำตัวของแอปพลิเคชันผ่านโฟลว์การขอโทเค็นตามเอกสาร และได้รับ access token จากนั้นจึงใส่โทเค็นดังกล่าวไว้ใน authorization header ของคำขอ API
แยกการยืนยันตัวตนออกจากตรรกะการติดตาม การออกแบบที่เหมาะสมควรมีคอมโพเนนต์หนึ่งสำหรับรับและแคชโทเค็นที่ถูกต้อง และอีกคอมโพเนนต์หนึ่งสำหรับเรียก tracking endpoint คอมโพเนนต์โทเค็นควร:
- ส่งข้อมูลประจำตัวไปยัง authorization endpoint ของ UPS ที่ระบุไว้ในเอกสารเท่านั้น
- ใช้ content type และพารามิเตอร์ grant ตามที่ระบุในเอกสาร UPS ปัจจุบัน
- จัดเก็บโทเค็นไว้ชั่วคราวและนำกลับมาใช้จนกว่าจะหมดอายุ แทนการขอโทเค็นใหม่สำหรับหมายเลขติดตามทุกหมายเลข
- รีเฟรชหรือขอโทเค็นใหม่เมื่อถึงเงื่อนไขการหมดอายุที่ระบุไว้ในเอกสาร
- ปกปิดข้อมูลประจำตัวและโทเค็นจากบันทึกแอปพลิเคชัน รายงานข้อผิดพลาด และคำร้องขอการสนับสนุน
อย่าคัดลอกโทเค็นจากเซสชันเบราว์เซอร์ไปใช้ในการเชื่อมต่อถาวร โดยทั่วไปบริการแบ็กเอนด์เป็นสถานที่ที่ปลอดภัยกว่าสำหรับจัดการข้อมูลประจำตัว เนื่องจากช่วยเก็บข้อมูลลับให้ห่างจากโค้ดไคลเอนต์สาธารณะ
ขั้นตอนที่ 4: สร้างคำขอติดตาม
ใช้รูปแบบคำขอที่แสดงในเอกสารอ้างอิง Tracking API อย่างเป็นทางการ โดยทั่วไปคำขอจะมีหมายเลขติดตามใน path หรือพารามิเตอร์คำขอ access token ใน authorization header และ header ที่ UPS API กำหนด อย่าสมมติว่าหมายเลขติดตามเป็นค่าเดียวที่จำเป็น เพราะเอกสารอ้างอิงปัจจุบันอาจกำหนด version, transaction, content-type หรือ correlation header
รูปแบบคำขออย่างง่ายมีลักษณะดังนี้:
GET [UPS tracking endpoint]/[tracking-number]
Authorization: Bearer [access-token]
Accept: application/jsonนี่เป็นเพียงตัวอย่างโครงสร้าง ไม่ใช่ endpoint ที่สามารถคัดลอกไปใช้ได้ทันที ให้ใช้ endpoint, version, header และชื่อพารามิเตอร์ที่ระบุในเอกสาร UPS สำหรับแอปพลิเคชันของคุณ จัดรูปแบบหมายเลขติดตามให้เป็นมาตรฐานตามกฎข้อมูลคำสั่งซื้อของคุณเอง แต่อย่าลบอักขระใดเว้นแต่เอกสารของผู้ให้บริการขนส่งจะยืนยันว่าปลอดภัย
ขั้นตอนที่ 5: แยกวิเคราะห์เหตุการณ์เข้าสู่โมเดลข้อมูล
การตอบกลับจากผู้ให้บริการขนส่งมักมีข้อมูลมากกว่าป้ายชื่อสถานะเพียงรายการเดียว ก่อนเขียนหน้าเว็บสำหรับลูกค้า ให้แมปการตอบกลับเข้าสู่โมเดลภายใน เช่น รหัสการจัดส่ง ผู้ให้บริการขนส่ง สถานะล่าสุด รหัสเหตุการณ์ คำอธิบายเหตุการณ์ เวลาของเหตุการณ์ สถานที่ ข้อมูลการจัดส่งโดยประมาณ และเวลาที่จัดส่งสำเร็จเมื่อมีข้อมูล
เก็บการตอบกลับต้นฉบับของผู้ให้บริการขนส่งไว้เมื่อเป็นไปตามนโยบายการเก็บรักษาและความเป็นส่วนตัว การตอบกลับดิบช่วยวินิจฉัยข้อผิดพลาดในการแมปหรืออธิบายว่าเหตุใดสถานะที่ปรับมาตรฐานของคุณจึงแตกต่างจากถ้อยคำของผู้ให้บริการขนส่ง ขณะเดียวกันควรหลีกเลี่ยงการแสดงรหัสเหตุการณ์ทางเทคนิคแก่ลูกค้าโดยไม่มีคำอธิบายที่อ่านเข้าใจได้
อย่าถือว่าสถานะทุกสถานะเป็นผลลัพธ์การจัดส่งขั้นสุดท้าย ตัวอย่างเช่น เหตุการณ์ระหว่างขนส่ง เหตุการณ์ผิดปกติ ความพยายามจัดส่ง และเหตุการณ์จัดส่งสำเร็จไม่ควรถูกรวมเป็นข้อความเดียวกันสำหรับลูกค้า สร้างการแมปอย่างชัดเจนและกำหนดว่าจะทำอย่างไรเมื่อ UPS เพิ่มค่าของเหตุการณ์ที่โค้ดของคุณไม่รู้จัก
ขั้นตอนที่ 6: เพิ่มการลองใหม่ การตรวจสอบ และการเฝ้าติดตาม
การเชื่อมต่อสำหรับใช้งานจริงต้องการมากกว่าคำขอที่สำเร็จในคอนโซลพัฒนา ให้เพิ่มการตรวจสอบและมาตรการป้องกันด้านปฏิบัติการ:
- การตรวจสอบอินพุต: ปฏิเสธหมายเลขติดตามที่ว่างเปล่า รูปแบบไม่ถูกต้อง หรือไม่ครบถ้วนอย่างเห็นได้ชัดก่อนส่งคำขอ
- Timeout: ป้องกันไม่ให้การตอบกลับจากผู้ให้บริการขนส่งที่ล่าช้าขัดขวางเวิร์กโฟลว์การชำระเงิน การสนับสนุน หรือคลังสินค้าทั้งหมด
- กฎการลองใหม่: ลองใหม่สำหรับความล้มเหลวชั่วคราวของเครือข่ายหรือบริการอย่างระมัดระวังโดยใช้ backoff อย่าลองซ้ำอย่างต่อเนื่องสำหรับข้อผิดพลาดด้านการยืนยันตัวตนหรือหมายเลขติดตามที่ไม่ถูกต้อง
- การตระหนักถึงอัตราการเรียก: ปฏิบัติตามขีดจำกัดและกฎการใช้งานในเอกสาร UPS แคชผลลัพธ์ล่าสุดเมื่อกระบวนการทางธุรกิจของคุณอนุญาต
- สถานะที่ไม่รู้จัก: เก็บเหตุการณ์ที่ไม่รู้จักไว้เพื่อตรวจสอบ แทนการติดป้ายผิดว่าเป็นจัดส่งสำเร็จหรือสูญหาย
- การสังเกตการณ์ระบบ: บันทึกเวลาคำขอ ประเภทการตอบกลับ และข้อมูล correlation โดยไม่บันทึกข้อมูลลับหรือข้อมูลส่วนบุคคลที่ไม่จำเป็น
ระบบติดตามควรกำหนดความถี่ในการรีเฟรชการจัดส่งด้วย การเรียกข้อมูลถี่เกินไปอาจสร้างภาระที่หลีกเลี่ยงได้และอาจไม่ก่อให้เกิดข้อมูลใหม่ การเรียกข้อมูลห่างเกินไปอาจทำให้หน้าที่แสดงต่อลูกค้าดูล้าสมัย เลือกช่วงเวลาตามปริมาณการจัดส่ง ความเร่งด่วนด้านปฏิบัติการ กฎของผู้ให้บริการขนส่ง และความสดใหม่ของข้อมูลที่ผู้ใช้ต้องการจริง
ขั้นตอนที่ 7: ทดสอบด้วยสถานการณ์จริง
ทดสอบมากกว่าการจัดส่งที่สำเร็จและส่งถึงแล้ว ให้รวมหมายเลขติดตามที่ไม่รู้จัก การจัดส่งระหว่างขนส่ง เหตุการณ์ผิดปกติ การจัดส่งที่มีหลายเหตุการณ์ โทเค็นหมดอายุ Timeout ความล้มเหลวในการอนุญาต และการตอบกลับที่มีฟิลด์ซึ่งตัวแยกวิเคราะห์ของคุณไม่คาดคิด หาก UPS มีสภาพแวดล้อมหรือข้อมูลประจำตัวสำหรับทดสอบแยกต่างหาก ให้ปฏิบัติตามขั้นตอนนั้นก่อน
ตรวจสอบเส้นทางทั้งหมดตั้งแต่คำขอจนถึงส่วนติดต่อผู้ใช้ ยืนยันว่าคำสั่งซื้อที่ถูกต้องได้รับการจัดส่งที่ถูกต้อง แสดงเวลาในเขตเวลาที่ต้องการ เหตุการณ์ซ้ำไม่สร้างข้อความซ้ำแก่ลูกค้า และระบบขัดข้องของผู้ให้บริการขนส่งไม่เขียนทับสถานะที่ถูกต้องก่อนหน้าด้วยข้อความที่ทำให้เข้าใจผิด
เมื่อใดควรใช้ Multi-Carrier Tracking API
การเชื่อมต่อ UPS โดยตรงเหมาะสมเมื่อการดำเนินงานของคุณจัดส่งสินค้ากับ UPS เป็นหลักและต้องการควบคุมเวิร์กโฟลว์ของผู้ให้บริการขนส่งอย่างใกล้ชิด แต่จะไม่สะดวกเท่าใดนักเมื่อคำสั่งซื้ออาจผ่านผู้ให้บริการขนส่งหลายราย มาร์เก็ตเพลส ผู้ให้บริการไปรษณีย์ หรือบริษัทจัดส่งระดับภูมิภาค ในกรณีนั้น ข้อมูลประจำตัว รูปแบบการตอบกลับ คำศัพท์สถานะ และกฎการลองใหม่ที่แตกต่างกันอาจเพิ่มภาระการบำรุงรักษา
บริการหลายผู้ให้บริการขนส่ง เช่น 17TRACK Tracking API อาจเป็นรูปแบบการเชื่อมต่อทางเลือกสำหรับแอปพลิเคชันที่ต้องการติดตามพัสดุจากผู้ให้บริการหลายราย ควรตรวจสอบเอกสารสำหรับนักพัฒนาโดยตรงเกี่ยวกับผู้ให้บริการที่รองรับ รูปแบบคำขอ การยืนยันตัวตน เงื่อนไขการใช้งาน และความสามารถที่มีให้ บริการนี้ไม่ได้ดีกว่าการเชื่อมต่อ UPS โดยตรงโดยอัตโนมัติ ทางเลือกที่เหมาะสมขึ้นอยู่กับสัดส่วนผู้ให้บริการขนส่ง ความต้องการข้อมูล การควบคุมการเชื่อมต่อ และข้อจำกัดด้านการค้าและการปฏิบัติตามกฎระเบียบ
สำหรับการค้นหาสำหรับผู้บริโภคแทนการเชื่อมต่อสำหรับนักพัฒนา หน้าติดตามของ 17TRACK อาจเหมาะสมกว่าการสร้างการเชื่อมต่อ API สำหรับร้านค้าออนไลน์ที่ต้องการอัปเดตหลังการซื้อในรูปแบบแบรนด์ของตนเอง ให้ตรวจสอบการเชื่อมต่อแพลตฟอร์มที่เกี่ยวข้องแยกต่างหาก แทนการเพิ่มงาน API ที่ร้านค้าไม่จำเป็นต้องใช้
ข้อผิดพลาดทั่วไปในการพัฒนา
- ใช้ตัวอย่างเก่า: ตัวอย่างโค้ดอาจอ้างถึงเวอร์ชันที่ยกเลิกแล้ว วิธีการยืนยันตัวตนแบบเก่า หรือบริการ UPS อื่น
- ใส่ข้อมูลลับในโค้ด frontend: ทุกสิ่งที่ส่งไปยังเบราว์เซอร์ควรถือว่าผู้ใช้สามารถตรวจสอบได้
- คิดว่าผลลัพธ์ว่างหมายถึงไม่มีการจัดส่ง: ตรวจสอบหมายเลขติดตาม สิทธิ์บัญชี สภาพแวดล้อม และข้อความตอบกลับก่อนสรุปผลทางธุรกิจ
- แมปเฉพาะข้อความ: คำอธิบายสถานะอาจแตกต่างกัน ใช้รหัสตามเอกสารและเก็บค่าที่ไม่รู้จักไว้ตรวจสอบ
- มองข้ามข้อกำหนดบัญชีและการใช้งาน: โค้ดทางเทคนิคอาจถูกต้อง แต่แอปพลิเคชันอาจไม่ได้รับการกำหนดค่าสำหรับบริการที่ร้องขอ
- รีเฟรชโดยไม่มีกฎทางธุรกิจ: การเรียกข้อมูลที่ไม่จำเป็นอาจเพิ่มต้นทุน ภาระระบบ และเสียงรบกวนด้านปฏิบัติการโดยไม่ปรับปรุงประสบการณ์ลูกค้า
เช็กลิสต์เตรียมเปิดใช้งานจริง
- ยืนยันว่าแอปพลิเคชันใช้เอกสาร UPS ปัจจุบันและสภาพแวดล้อมที่ได้รับอนุมัติ
- ตรวจสอบว่าข้อมูลประจำตัวจัดเก็บไว้ฝั่งเซิร์ฟเวอร์และสามารถหมุนเวียนได้
- ทดสอบความล้มเหลวในการยืนยันตัวตน ข้อผิดพลาดของผู้ให้บริการขนส่ง อินพุตที่มีรูปแบบไม่ถูกต้อง และ Timeout
- เปรียบเทียบสถานะที่ปรับมาตรฐานกับการตอบกลับต้นฉบับสำหรับการจัดส่งตัวอย่าง
- กำหนดนโยบายการรีเฟรชและติดตามปริมาณคำขอ
- กำหนดผู้รับผิดชอบเหตุการณ์ที่ไม่ระบุชื่อ การอัปเดตล่าช้า และการยกระดับปัญหาของลูกค้า
- จัดทำเอกสารการเชื่อมต่อเพื่อให้นักพัฒนาคนอื่นสามารถอัปเดตข้อมูลประจำตัว เวอร์ชัน endpoint และการแมปสถานะได้อย่างปลอดภัย
คำถามที่พบบ่อย
ฉันต้องมีบัญชี UPS เพื่อใช้ Tracking API หรือไม่?
ควรตรวจสอบข้อกำหนดการเริ่มต้นใช้งานและการเข้าถึง UPS ปัจจุบันใน Developer Portal การเข้าถึง API อาจขึ้นอยู่กับการลงทะเบียนแอปพลิเคชัน ข้อมูลประจำตัว การกำหนดค่าบัญชี และบริการเฉพาะที่ร้องขอ อย่าสมมติว่าการเข้าสู่ระบบหน้าติดตามสาธารณะสามารถใช้แทนการเข้าถึง developer API ได้
UPS Tracking API ใช้งานฟรีหรือไม่?
อย่าสมมติว่าการเข้าถึง API ไม่มีเงื่อนไขทางการค้าหรือการใช้งาน UPS เผยแพร่ข้อมูลบริการและบัญชีปัจจุบันผ่านช่องทางอย่างเป็นทางการ และข้อกำหนดบางอย่างอาจขึ้นอยู่กับผลิตภัณฑ์ บัญชี หรือข้อตกลง โปรดยืนยันเงื่อนไขที่ใช้โดยตรงก่อนวางแผนงบประมาณสำหรับการใช้งานจริง
ฉันสามารถเรียก UPS API โดยตรงจาก JavaScript ในเบราว์เซอร์ได้หรือไม่?
การเรียกจากเบราว์เซอร์อาจเปิดเผยข้อมูลประจำตัวของแอปพลิเคชันและสร้างปัญหาด้าน cross-origin ความปลอดภัย และการควบคุมการใช้งาน โดยทั่วไปการเชื่อมต่อฝั่งเซิร์ฟเวอร์เป็นรูปแบบที่ปลอดภัยกว่าสำหรับจัดเก็บข้อมูลลับ รับโทเค็น ใช้กฎการลองใหม่ และจำกัดการเข้าถึงข้อมูลการจัดส่ง
แอปพลิเคชันควรขออัปเดตการติดตามบ่อยแค่ไหน?
ใช้นโยบายการรีเฟรชตามขีดจำกัดที่ผู้ให้บริการขนส่งระบุ ปริมาณการจัดส่ง ความเร่งด่วนด้านปฏิบัติการ และความสดใหม่ของข้อมูลที่ผู้ใช้ต้องการ แคชผลลัพธ์ล่าสุดเมื่อเหมาะสม ใช้ backoff หลังความล้มเหลวชั่วคราว และอย่าถือว่าการเรียกซ้ำเป็นสิ่งทดแทนความสามารถด้านเหตุการณ์หรือการแจ้งเตือนที่มีเอกสารรองรับ
ควรใช้การเชื่อมต่อ UPS โดยตรงหรือ multi-carrier API?
การเชื่อมต่อ UPS โดยตรงอาจเหมาะกับเวิร์กโฟลว์ที่เน้น UPS และต้องการการควบคุมเฉพาะผู้ให้บริการขนส่ง ส่วน multi-carrier API อาจลดจำนวนการเชื่อมต่อเมื่อการจัดส่งของคุณใช้ผู้ให้บริการหลายราย ให้เปรียบเทียบผู้ให้บริการที่รองรับ การยืนยันตัวตน ฟิลด์ข้อมูล ข้อกำหนดด้านความน่าเชื่อถือ เงื่อนไขการใช้งาน และความพยายามในการพัฒนาก่อนตัดสินใจ
แหล่งข้อมูล
- UPS Developer Portal — แคตตาล็อก API การเข้าถึงแอปพลิเคชัน การยืนยันตัวตน และเอกสารสำหรับนักพัฒนาอย่างเป็นทางการ
- UPS Technology Integration — ข้อมูลอย่างเป็นทางการเกี่ยวกับการเชื่อมต่อเทคโนโลยี UPS กับระบบธุรกิจ
- 17TRACK Tracking API — จุดเริ่มต้นผลิตภัณฑ์และนักพัฒนาอย่างเป็นทางการสำหรับการติดตามหลายผู้ให้บริการขนส่ง
- 17TRACK API Documentation — เอกสาร API อย่างเป็นทางการสำหรับการยืนยันตัวตน คำขอ และการจัดการการตอบกลับ
