UPS Tracking Api เทียบกับการผสานรวม OMS: คุณควรเลือกอะไร?

หากคุณต้องการเพียงสถานะการจัดส่ง ให้เลือก UPS tracking API หากคุณต้องประสานงานคำสั่งซื้อ สินค้าคงคลัง การดำเนินการตามคำสั่งซื้อ การกำหนดเส้นทาง การยกเลิก และการคืนสินค้าผ่านหลายช่องทาง ให้เลือกการผสานรวม OMS ในการดำเนินงานอีคอมเมิร์ซจำนวนมาก คำตอบในทางปฏิบัติไม่ใช่การเลือกอย่างใดอย่างหนึ่งเสมอไป: OMS จัดการวงจรชีวิตคำสั่งซื้อ ขณะที่ carrier หรือ multi-carrier tracking API จัดหาเหตุการณ์การจัดส่ง

การตัดสินใจที่เหมาะสมขึ้นอยู่กับการดำเนินการที่ทีมของคุณต้องทำ นักพัฒนาที่สร้างหน้าติดตามพัสดุมีความต้องการแตกต่างจากทีมปฏิบัติการที่เชื่อมต่อ marketplace คลังสินค้า 3PL และระบบบริการลูกค้า การมอง UPS tracking API และ OMS ว่าสามารถใช้แทนกันได้ อาจทำให้เกิดงานพัฒนาที่ไม่จำเป็นหรือทำให้เกิดช่องว่างสำคัญในการดำเนินงาน

ความแตกต่างในหนึ่งประโยค

UPS tracking API คือการเชื่อมต่อข้อมูลจากผู้ให้บริการขนส่ง ส่วนการผสานรวม OMS คือการเชื่อมต่อเวิร์กโฟลว์คำสั่งซื้อ

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

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

เมื่อใดควรเลือก UPS tracking API

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

• การติดตามสำหรับลูกค้า: เว็บไซต์หรือแอปของคุณต้องแสดงความคืบหน้าของการจัดส่ง โดยไม่บังคับให้ลูกค้าออกจากประสบการณ์การใช้งาน
• เวิร์กโฟลว์ฝ่ายสนับสนุน: เจ้าหน้าที่ต้องการเหตุการณ์การติดตามล่าสุดภายใน help desk, CRM หรือหน้าคำสั่งซื้อ
• การแจ้งเตือนการจัดส่ง: ระบบของคุณต้องใช้เหตุการณ์การจัดส่งเป็นข้อมูลนำเข้าสำหรับอีเมล SMS หรือการสื่อสารกับลูกค้ารูปแบบอื่น
• การตรวจสอบเหตุการณ์ผิดปกติ: เจ้าหน้าที่ปฏิบัติการต้องระบุความล่าช้า ความพยายามจัดส่ง หรือเหตุการณ์อื่นที่ต้องติดตามเพิ่มเติม
• การดำเนินงานกับผู้ให้บริการขนส่งรายเดียว: UPS จัดการการจัดส่งที่เกี่ยวข้องส่วนใหญ่หรือทั้งหมด ดังนั้นการผสานรวมเฉพาะผู้ให้บริการรายเดียวจึงเหมาะสมในเชิงปฏิบัติการ

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

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

เมื่อใดควรเลือกการผสานรวม OMS

เลือกการผสานรวม OMS เมื่อปัญหาเริ่มต้นก่อนการสร้างการจัดส่ง หรือดำเนินต่อไปเกินกว่าการมองเห็นข้อมูลจากผู้ให้บริการขนส่ง

OMS มีความเกี่ยวข้องมากกว่าเมื่อธุรกิจจำเป็นต้องประสานงานหลายรายการต่อไปนี้:

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

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

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

UPS tracking API เทียบกับการผสานรวม OMS

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

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

ตัวเลือกที่ธุรกิจที่กำลังเติบโตจำนวนมากต้องการ: OMS ร่วมกับ multi-carrier tracking

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

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

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

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

วิธีเลือกโดยไม่สร้างระบบเกินความจำเป็น

1. เริ่มจากเหตุการณ์ทางธุรกิจ

เขียนเหตุการณ์ที่ต้องกระตุ้นให้เกิดการดำเนินการ “แสดงสถานะ UPS ล่าสุดบนหน้าคำสั่งซื้อ” ชี้ไปที่ tracking API ส่วน “ส่งคำสั่งซื้อที่ชำระเงินแล้วแต่ละรายการไปยังสถานที่ดำเนินการตามคำสั่งซื้อที่เหมาะสมที่สุด และรักษาการซิงโครไนซ์สินค้าคงคลัง” ชี้ไปที่ OMS ขณะที่ “อัปเดตลูกค้าหลังจากพัสดุออกจาก 3PL” อาจต้องใช้ทั้งสองอย่าง

2. ระบุระบบที่เป็นเจ้าของข้อมูลอยู่แล้ว

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

3. ตรวจสอบความหลากหลายของผู้ให้บริการขนส่งและภูมิศาสตร์

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

4. กำหนดโมเดลสถานะขั้นต่ำ

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

5. ทดสอบเหตุการณ์ผิดปกติในการดำเนินงาน

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

6. เปรียบเทียบภาระการดำเนินงานทั้งหมด

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

กฎการตัดสินใจในทางปฏิบัติ

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

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

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

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

UPS tracking API เหมือนกับ OMS หรือไม่

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

OMS สามารถติดตามการจัดส่งของ UPS ได้หรือไม่

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

ฉันจำเป็นต้องมี OMS เพื่อสร้างหน้าติดตามที่มีแบรนด์หรือไม่

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

ควรใช้ multi-carrier tracking API เมื่อใด

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

นักพัฒนาควรทำความชัดเจนเรื่องใดก่อนการผสานรวม

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

แหล่งข้อมูล

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