Tracking API กับ Shipping API: สแต็กอีคอมเมิร์ซของคุณต้องใช้ตัวไหน (หรือทั้งสองอย่าง)?
ใช้ shipping API เมื่อระบบอีคอมเมิร์ซของคุณจำเป็นต้องสร้างรายการจัดส่งและสร้างใบปะหน้าพัสดุ ใช้ tracking API เมื่อต้องติดตามการจัดส่งหลังจากส่งออกไปแล้ว และเปลี่ยนข้อมูลอัปเดตจากผู้ให้บริการขนส่งให้เป็นข้อมูลที่เป็นประโยชน์ต่อการดำเนินงานหรือลูกค้า คุณต้องมีความสามารถทั้งสองอย่างหากซอฟต์แวร์ของคุณต้องจัดการการสร้างรายการจัดส่งและการมองเห็นสถานะหลังการซื้อ แต่ไม่จำเป็นต้องใช้ผู้ให้บริการสองรายหรือการเชื่อมต่อแยกกันสองชุดเสมอไป
การตัดสินใจนี้ควรเป็นหน้าที่ของผู้รับผิดชอบสถาปัตยกรรมการจัดส่งสินค้า โดยทั่วไปคือหัวหน้าฝ่ายปฏิบัติการอีคอมเมิร์ซที่ทำงานร่วมกับทีมวิศวกรรม เริ่มจากการระบุว่าสโตร์ คลังสินค้า หรือพันธมิตรด้านการจัดส่งของคุณจัดการอะไรอยู่แล้ว การเพิ่ม API อีกตัวควรแก้ช่องว่างที่เฉพาะเจาะจง ไม่ใช่ทำซ้ำเวิร์กโฟลว์ที่ทำงานได้ดีอยู่แล้ว
tracking API และ shipping API แตกต่างกันอย่างไร
ความแตกต่างหลักอยู่ที่งานที่ API แต่ละตัวทำ ไม่ใช่เส้นแบ่งตายตัวระหว่างหมวดหมู่ผลิตภัณฑ์ แพลตฟอร์มการจัดส่งอาจมี endpoint สำหรับการติดตาม ขณะที่บริการติดตามอาจมีเครื่องมือสำหรับการแจ้งเตือนและอัปเดตการจัดส่งที่สื่อสารกับลูกค้าได้ ควรประเมิน endpoint ที่มีการจัดทำเอกสารไว้และพฤติกรรมของอีเวนต์ แทนที่จะพึ่งพาชื่อผลิตภัณฑ์
| มิติของการตัดสินใจ | Tracking API | Shipping API |
|---|---|---|
| งานหลัก | เรียกดูหรือรับสถานะการจัดส่งและอีเวนต์การติดตาม | สร้างรายการจัดส่งและรับใบปะหน้าพัสดุรวมถึงเอกสารการจัดส่งที่เกี่ยวข้อง |
| ข้อมูลนำเข้าที่พบโดยทั่วไป | หมายเลขติดตาม รหัสผู้ให้บริการขนส่ง และรายละเอียดการจัดส่งเพิ่มเติมที่จำเป็น | รายละเอียดผู้ส่งและผู้รับ ข้อมูลพัสดุ การเลือกบริการ และข้อมูลศุลกากรที่เกี่ยวข้อง |
| ข้อมูลส่งออกที่พบโดยทั่วไป | สถานะการจัดส่ง ประวัติอีเวนต์ และข้อมูลการจัดส่งอื่น ๆ ที่มีอยู่ | รหัสรายการจัดส่ง ใบปะหน้าพัสดุ และเอกสารที่รองรับ |
| เวิร์กโฟลว์หลัก | การมองเห็นสถานะการจัดส่ง การจัดการข้อยกเว้น และการอัปเดตหลังการซื้อ | การส่งออกจากคลังสินค้าและการเตรียมพัสดุสำหรับจัดส่ง |
| สิ่งที่ไม่ควรสันนิษฐาน | การเข้าถึงข้อมูลติดตามจะรวมการสร้างใบปะหน้าพัสดุหรือการจองบริการขนส่ง | การสร้างใบปะหน้าพัสดุจะรวมรายละเอียดการติดตามและการควบคุมการแจ้งเตือนที่คุณต้องการ |
เอกสารของผู้ให้บริการขนส่งแสดงให้เห็นถึงการแยกหน้าที่นี้ FedEx จัดทำเอกสารการสร้างรายการจัดส่งไว้ใน เอกสาร Ship API และความสามารถด้านการติดตามไว้ใน เอกสาร tracking API สิ่งเหล่านี้เป็นตัวอย่างของความรับผิดชอบทางเทคนิคที่แตกต่างกัน ไม่ใช่คำแนะนำให้เลือกผู้ให้บริการขนส่งรายใดรายหนึ่ง
การสร้างรายการจัดส่งไม่เหมือนกับการติดตามการเคลื่อนย้าย
การตอบกลับที่สำเร็จจากการสร้างรายการจัดส่งบอกซอฟต์แวร์ของคุณเพียงว่าคำขอจัดส่งได้รับการประมวลผลแล้ว ไม่ได้ยืนยันว่าผู้ให้บริการขนส่งได้รับพัสดุจริงแล้ว ในทำนองเดียวกัน หมายเลขติดตามอาจมีอยู่ก่อนที่ข้อมูลการเคลื่อนย้ายจะปรากฏในประวัติการติดตาม
ดังนั้นระบบจัดการคำสั่งซื้อของคุณควรแยกแยะระหว่างการสร้างใบปะหน้าพัสดุ การส่งมอบให้คลังสินค้าหรือผู้ขนส่ง การรับพัสดุโดยผู้ให้บริการขนส่ง และการจัดส่งถึงปลายทาง การถือว่าทั้งหมดนี้เป็นอีเวนต์ “จัดส่งแล้ว” เดียวกันอาจทำให้ส่งข้อความถึงลูกค้าเร็วเกินไป และทำให้มองไม่เห็นพัสดุที่ยังไม่ได้ออกจากคลังสินค้าจริง
เลือกความสามารถที่แก้คอขวดปัจจุบันของคุณ
เลือก shipping API เมื่อส่วนที่ขาดหายคือการส่งออก
shipping API คือจุดเริ่มต้นที่เหมาะสมเมื่อแอปพลิเคชันของคุณต้องเปลี่ยนข้อมูลคำสั่งซื้อให้เป็นรายการจัดส่ง ตัวอย่างเช่น ทีมคลังสินค้าต้องคัดลอกที่อยู่ลงในพอร์ทัลของผู้ให้บริการขนส่งด้วยตนเอง หรือระบบจัดการคำสั่งซื้อแบบกำหนดเองไม่สามารถสร้างใบปะหน้าพัสดุได้
ก่อนเลือกการเชื่อมต่อ ให้กำหนดเวิร์กโฟลว์การส่งออกที่แท้จริง คุณต้องการเพียงการสร้างรายการจัดส่ง หรือจำเป็นต้องเรียกดูอัตราค่าจัดส่ง การยกเลิก คำขอเข้ารับพัสดุ เอกสารศุลกากร หรือกระบวนการสิ้นวันด้วย ฟังก์ชันเหล่านี้อาจเป็น API แยกกัน ขึ้นอยู่กับผู้ให้บริการขนส่ง หรือต้องใช้สิทธิ์เพิ่มเติมในบัญชี อย่าสันนิษฐานว่าผลิตภัณฑ์ที่มีชื่อว่า “shipping API” จะรวมการดำเนินการด้านการจัดส่งทุกอย่าง
ไม่เหมาะที่จะใช้เป็นโซลูชันเดียว: การเชื่อมต่อสำหรับสร้างใบปะหน้าพัสดุที่ทำให้ทีมบริการลูกค้าต้องตรวจสอบเว็บไซต์ของผู้ให้บริการขนส่งแต่ละรายด้วยตนเอง วิธีนี้อาจแก้ปัญหาการส่งออกได้ แต่แทบไม่ช่วยให้การมองเห็นสถานะการจัดส่งดีขึ้น
เลือก tracking API เมื่อการสร้างรายการจัดส่งทำงานได้อยู่แล้ว
tracking API เหมาะกว่าเมื่อระบบจัดการคลังสินค้า พันธมิตรด้านการจัดส่ง มาร์เก็ตเพลส หรือการเชื่อมต่อการจัดส่งที่มีอยู่สร้างใบปะหน้าพัสดุให้แล้ว แต่ข้อมูลการจัดส่งกระจัดกระจาย
ในสถานการณ์นี้ การเปลี่ยนเวิร์กโฟลว์การสร้างใบปะหน้าพัสดุอาจเพิ่มงานย้ายระบบโดยไม่แก้ปัญหาหลัก แต่ควรเชื่อมหมายเลขติดตามที่สร้างจากระบบต้นทางเข้ากับชั้นการมองเห็นสถานะ ซึ่งระบบจัดการคำสั่งซื้อ เครื่องมือสนับสนุน และการสื่อสารกับลูกค้าของคุณสามารถใช้งานได้
สำหรับหมวดหมู่นี้ 17TRACK Tracking API เป็นตัวเลือกการเชื่อมต่อที่เกี่ยวข้อง โดย เอกสาร API อย่างเป็นทางการ อธิบายเวิร์กโฟลว์การลงทะเบียนหมายเลขติดตามและข้อมูลการติดตาม รวมถึงการแจ้งเตือนแบบพุช ให้ประเมินเวิร์กโฟลว์เหล่านี้เทียบกับผู้ให้บริการขนส่ง ประเภทพัสดุ และสถาปัตยกรรมแอปพลิเคชันที่คุณต้องการ นี่เป็นข้อพิจารณาสำหรับชั้นการติดตาม ไม่ใช่หลักฐานว่าบริการนี้สามารถแทนที่การเชื่อมต่อสำหรับสร้างใบปะหน้าพัสดุได้
ไม่เหมาะที่จะใช้เป็นโซลูชันเดียว: tracking API ในกรณีที่ซอฟต์แวร์ของคุณยังไม่มีวิธีสร้างรายการจัดส่งที่รับผิดชอบการส่งออก การมองเห็นสถานะการติดตามไม่สามารถแก้ปัญหาการขาดความสามารถในการดำเนินการจัดส่งได้
ใช้ทั้งสองอย่างเมื่อแอปพลิเคชันของคุณรับผิดชอบการส่งออกและการมองเห็นสถานะการจัดส่ง
ควรใช้ความสามารถทั้งสองอย่างเมื่อระบบของคุณต้องสร้างใบปะหน้าพัสดุและรักษามุมมองที่เชื่อถือได้เกี่ยวกับความคืบหน้าของการจัดส่ง ความสามารถเหล่านี้อาจมาจากแพลตฟอร์มเดียว บริการแยกกัน หรือการผสมผสานระหว่างการเชื่อมต่อของผู้ให้บริการขนส่งกับชั้นการติดตาม
ควรเลือกการเชื่อมต่อเดียวเมื่อฟังก์ชันการจัดส่งและการติดตามของการเชื่อมต่อนั้นตรงตามข้อกำหนดที่จัดทำเป็นเอกสารไว้ โดยไม่บังคับให้ยอมประนีประนอมโดยไม่จำเป็น พิจารณาการเชื่อมต่อแยกกันเมื่อเวิร์กโฟลว์การจัดส่งที่มีอยู่ควรรักษาไว้ หรือเมื่อข้อกำหนดด้านการติดตามแตกต่างอย่างมีนัยสำคัญจากสิ่งที่เวิร์กโฟลว์นั้นมีให้ ผู้ให้บริการติดตามแยกต่างหากไม่ได้ดีกว่าโดยอัตโนมัติ แต่ต้องคุ้มค่ากับภาระด้านการเชื่อมต่อ การเรียกเก็บเงิน และการดูแลการดำเนินงานที่เพิ่มขึ้น
API ทั้งสองประเภทเข้ากับระบบอีคอมเมิร์ซอย่างไร
การออกแบบที่ใช้งานได้จริงควรเก็บคำสั่งซื้อ รายการจัดส่ง และอีเวนต์การติดตามเป็นระเบียนแยกกัน คำสั่งซื้อหนึ่งรายการอาจสร้างพัสดุได้หลายชิ้น และพัสดุแต่ละชิ้นอาจมีประวัติการติดตามของตนเอง สถานะคำสั่งซื้อที่แสดงต่อลูกค้าควรคำนวณจากระเบียนการจัดส่งเหล่านั้น แทนที่จะเขียนทับระเบียนเดิม
- คำสั่งซื้อพร้อมสำหรับการจัดส่ง สโตร์หรือระบบจัดการคำสั่งซื้อส่งข้อมูลการจัดส่งที่จำเป็นไปยังคลังสินค้าที่รับผิดชอบ
- เวิร์กโฟลว์การจัดส่งสร้างรายการจัดส่ง แอปพลิเคชันจัดเก็บรหัสรายการจัดส่ง หมายเลขติดตาม ผู้ให้บริการขนส่ง บริการ และข้อมูลอ้างอิงใบปะหน้าพัสดุที่ส่งกลับมา
- คลังสินค้าดำเนินการส่งมอบเสร็จสิ้น การยืนยันจากคลังสินค้าและการรับพัสดุโดยผู้ให้บริการขนส่งยังคงเป็นอีเวนต์ที่แยกแยะได้
- เวิร์กโฟลว์การติดตามเริ่มต้น แอปพลิเคชันของคุณลงทะเบียนหรือส่งหมายเลขติดตามตามที่การเชื่อมต่อที่เลือกกำหนด
- การอัปเดตการติดตามมาถึงแอปพลิเคชัน Webhook, การโพล หรือการผสมผสานที่รองรับจะป้อนข้อมูลเข้าสู่ระเบียนการจัดส่ง
- กฎทางธุรกิจตัดสินใจขั้นตอนถัดไป ระบบของคุณอัปเดตสถานะที่แสดงต่อลูกค้า สร้างงานด้านการดำเนินงาน หรือส่งข้อความเมื่อเงื่อนไขที่เกี่ยวข้องครบถ้วน
ตัวอย่างเช่น ผู้ค้าที่ใช้คลังสินค้าจัดส่งสินค้าของบุคคลที่สามอาจต้องใช้เพียงขั้นตอนที่สี่ถึงหกในซอฟต์แวร์ของตนเอง เนื่องจากคลังสินค้าเป็นผู้รับผิดชอบการสร้างรายการจัดส่งอยู่แล้ว ผู้ค้าที่ดำเนินการคลังสินค้าด้วยตนเองอาจต้องใช้กระบวนการทั้งหมด
กำหนดผู้รับผิดชอบหนึ่งรายสำหรับการดำเนินการต่อเนื่องแต่ละอย่าง
หากการเชื่อมต่อทั้งสองชุดส่งข้อมูลอัปเดตการติดตาม ให้กำหนดว่าระบบใดควบคุมการแจ้งเตือนลูกค้าและสถานะการจัดส่งที่แสดงในสโตร์ มิฉะนั้นลูกค้าอาจได้รับข้อความซ้ำหรือเห็นสถานะการจัดส่งที่ขัดแย้งกัน
คุณสามารถเก็บข้อมูลสำรองไว้เพื่อการตรวจสอบโดยไม่อนุญาตให้ทุกแหล่งข้อมูลส่งอีเมลได้ เก็บอีเวนต์ต้นฉบับจากผู้ให้บริการขนส่งไว้พร้อมกับการจับคู่สถานะภายใน เพื่อให้เจ้าหน้าที่สนับสนุนเข้าใจว่าเหตุใดระบบจึงจัดประเภทการจัดส่งในลักษณะนั้น
เปรียบเทียบความเหมาะสมต่อการดำเนินงาน ไม่ใช่ป้ายชื่อฟีเจอร์
ตรวจสอบผู้ให้บริการขนส่งและบริการที่คุณใช้งานจริง
การรองรับผู้ให้บริการขนส่งไม่ใช่คำถามแบบใช่หรือไม่ใช่เพียงข้อเดียว บริการหนึ่งอาจรองรับการติดตามสำหรับผู้ให้บริการขนส่งรายหนึ่ง แต่ไม่รองรับการสร้างใบปะหน้าพัสดุสำหรับผู้ให้บริการรายนั้น การสร้างใบปะหน้าพัสดุอาจขึ้นอยู่กับประเทศต้นทาง การตั้งค่าบัญชีผู้ให้บริการขนส่ง หรือคุณสมบัติของบริการด้วย
สร้างรายการทดสอบจากเส้นทางการจัดส่งจริงของคุณ รวมพัสดุภายในประเทศ การจัดส่งระหว่างประเทศ และการส่งมอบระหว่างพันธมิตรด้านการขนส่ง ยืนยันการดำเนินการที่จำเป็นสำหรับแต่ละรายการ ได้แก่ การสร้างรายการจัดส่ง การติดตาม หรือทั้งสองอย่าง ข้อความระบุการครอบคลุมในวงกว้างมีประโยชน์น้อยกว่าการทดสอบบริการที่ธุรกิจของคุณพึ่งพาจนสำเร็จ
ตรวจสอบความหมายของอีเวนต์และความครบถ้วนของข้อมูล
สำหรับการติดตาม ให้ทดสอบสิ่งที่เกิดขึ้นก่อนการสแกนครั้งแรก ระหว่างเกิดข้อยกเว้นในการจัดส่ง หลังจากพยายามจัดส่งไม่สำเร็จ และเมื่อจัดส่งสำเร็จ ตรวจสอบว่าการประทับเวลามีข้อมูลเขตเวลาหรือไม่ และคำอธิบายต้นฉบับจากผู้ให้บริการขนส่งยังคงมีอยู่หรือไม่
อย่าตีความสถานะที่ทำให้เป็นมาตรฐานว่าเป็นคำมั่นว่าจะมีข้อมูลเหมือนกันจากผู้ให้บริการขนส่งทุกราย วันที่คาดว่าจะจัดส่ง รายละเอียดสถานที่ และข้อมูลหลักฐานการจัดส่งอาจขึ้นอยู่กับผู้ให้บริการขนส่งและพัสดุแต่ละรายการ ตัดสินใจว่าอินเทอร์เฟซของคุณจะทำงานอย่างไรเมื่อไม่มีข้อมูลเหล่านี้
ตรวจสอบการกู้คืนจากข้อผิดพลาดทั้งสองด้าน
สำหรับการจัดส่ง ให้ความสำคัญเป็นพิเศษกับ timeout ระหว่างการสร้างรายการจัดส่ง คำขออาจสำเร็จแล้วแม้แอปพลิเคชันของคุณจะไม่ได้รับการตอบกลับ ตรวจสอบกลไกป้องกันรายการซ้ำและการกระทบยอดที่ผู้ให้บริการรองรับก่อนลองใหม่โดยไม่ตรวจสอบ
สำหรับการติดตาม ให้ทดสอบการแจ้งเตือนซ้ำ อีเวนต์ล่าช้า การส่ง webhook ไม่สำเร็จ และ endpoint ขัดข้องชั่วคราว ยืนยันการตรวจสอบสิทธิ์ พฤติกรรมการลองใหม่ และตัวเลือกการกู้คืนในเอกสารที่เกี่ยวข้อง ออกแบบการประมวลผลอีเวนต์เพื่อให้การเล่นซ้ำของการอัปเดตไม่ส่งการแจ้งเตือนลูกค้ารายเดิมอีกครั้ง
เปรียบเทียบต้นทุนการดำเนินงานทั้งหมดโดยไม่สันนิษฐานรูปแบบราคา
แยกค่าบริการ API ออกจากค่าจัดส่งไปรษณีย์และค่าบัญชีผู้ให้บริการขนส่ง บริการจัดส่งและบริการติดตามอาจใช้หน่วยเรียกเก็บเงินต่างกัน และแพลตฟอร์มแบบรวมอาจจัดแพ็กเกจความสามารถแตกต่างกัน ขอใบเสนอราคาหรือตรวจสอบแผนที่เกี่ยวข้องสำหรับเวิร์กโฟลว์ที่คุณตั้งใจจะใช้งานโดยเฉพาะ
สอบถามว่านิยามการใช้งานที่เรียกเก็บเงินเป็นอย่างไร คำขอที่ไม่สำเร็จถูกนับหรือไม่ การส่งข้อมูลติดตามซ้ำได้รับการจัดการอย่างไร และจะเกิดอะไรขึ้นเมื่อการใช้งานเกินโควตา รวมค่าบำรุงรักษาด้านวิศวกรรม ความพยายามในการสนับสนุน และต้นทุนในการทำให้การเชื่อมต่อสองชุดสอดคล้องกัน หากไม่มีสัดส่วนประเภทพัสดุและเงื่อนไขทางการค้าปัจจุบันที่กำหนดไว้อย่างชัดเจน การบอกว่าหมวดหมู่ใดถูกกว่าจะทำให้เข้าใจผิด
ทบทวนความปลอดภัยและการเก็บรักษาข้อมูล
การเชื่อมต่อด้านการจัดส่งอาจประมวลผลที่อยู่ผู้รับและข้อมูลศุลกากร การเชื่อมต่อด้านการติดตามอาจประมวลผลรหัสรายการจัดส่งและข้อมูลลูกค้าที่เกี่ยวข้องด้วย ยืนยันว่าต้องใช้ฟิลด์ใด จำกัดข้อมูลรับรองให้มีสิทธิ์เท่าที่จำเป็น และเก็บความลับออกจากโค้ดฝั่งเบราว์เซอร์
ทบทวนการเก็บรักษา การลบ และการควบคุมการเข้าถึงให้สอดคล้องกับข้อกำหนดทางธุรกิจของคุณ การเชื่อมต่อที่สะดวกไม่ควรบังคับให้ส่งข้อมูลลูกค้าที่เวิร์กโฟลว์ไม่จำเป็นต้องใช้
แผนตรวจสอบที่ใช้งานได้จริงก่อนตัดสินใจ
ทำ proof of concept โดยใช้พัสดุที่เป็นตัวแทนของการใช้งานจริง แทนที่จะทดสอบเฉพาะตัวอย่างที่สำเร็จจากคู่มือเริ่มต้นใช้งานอย่างรวดเร็ว กำหนดเกณฑ์การยอมรับร่วมกับฝ่ายปฏิบัติการ วิศวกรรม และฝ่ายบริการลูกค้า
- การส่งออก: สร้างรูปแบบใบปะหน้าพัสดุที่จำเป็น และยืนยันว่าอุปกรณ์ของคลังสินค้าสามารถใช้งานได้
- การจับคู่คำสั่งซื้อ: ทดสอบการจัดส่งแบบแบ่งส่วน พัสดุหลายชิ้น และการจัดส่งทดแทนโดยไม่สูญเสียประวัติเดิม
- การติดตาม: ตรวจสอบลำดับอีเวนต์จริงสำหรับผู้ให้บริการขนส่งและเส้นทางที่สำคัญต่อธุรกิจ
- ข้อยกเว้น: ยืนยันว่าปัญหาการจัดส่งที่ต้องดำเนินการถูกส่งไปยังทีมที่ถูกต้อง โดยไม่ถือว่าการสแกนผิดปกติทุกครั้งเป็นความล้มเหลวโดยอัตโนมัติ
- การกู้คืน: ทำให้คำขอหรือ endpoint ของ webhook หยุดชะงัก และสาธิตว่าแอปพลิเคชันจะกระทบยอดข้อมูลที่ขาดหายอย่างไร
- การสื่อสาร: ยืนยันว่าเฉพาะระบบที่กำหนดเท่านั้นที่ส่งการแจ้งเตือนลูกค้าแต่ละรายการ
- ความเหมาะสมทางการค้า: ประมาณค่าบริการโดยใช้การใช้งานที่คาดไว้และนิยามการเรียกเก็บเงินที่ผู้ให้บริการยืนยันแล้ว
กฎการตัดสินใจ: ซื้อความสามารถที่ขาดหายก่อน หากการส่งออกทำงานได้อยู่แล้ว ให้ประเมินการเชื่อมต่อด้านการติดตามโดยไม่สร้างกระบวนการจัดส่งใหม่ หากขาดการสร้างใบปะหน้าพัสดุ ให้แก้ปัญหาการดำเนินการจัดส่งก่อน หากแอปพลิเคชันของคุณรับผิดชอบวงจรชีวิตการจัดส่งทั้งหมด ให้ตรวจสอบความสามารถทั้งสองด้าน และเลือกว่าสถาปัตยกรรมแบบรวมเป็นหนึ่งเดียวหรือแบบแยกกันนั้นง่ายต่อการดำเนินงานสำหรับทีมของคุณมากกว่า
คำถามที่พบบ่อย
shipping API มีการติดตามรวมอยู่ด้วยเสมอหรือไม่
ไม่เสมอไป บริการบางรายมีทั้งสองความสามารถ ขณะที่บางรายเปิดให้ใช้งานผ่าน endpoint ผลิตภัณฑ์ หรือแผนบริการแยกกัน แม้จะมีการติดตามรวมอยู่ด้วย ก็ควรตรวจสอบรายละเอียดอีเวนต์ วิธีส่งการอัปเดต การรองรับผู้ให้บริการขนส่ง และเงื่อนไขการใช้งานก่อนถือว่าเป็นโซลูชันการติดตามหลังการซื้อของคุณ
ฉันสามารถติดตามพัสดุที่สร้างใบปะหน้าโดยพันธมิตรด้านการจัดส่งได้หรือไม่
อาจทำได้ แอปพลิเคชันของคุณต้องมีรหัสที่การเชื่อมต่อด้านการติดตามกำหนด โดยทั่วไปได้แก่หมายเลขติดตาม และในกรณีที่จำเป็น รหัสผู้ให้บริการขนส่งหรือข้อมูลยืนยันเพิ่มเติม ยืนยันว่ารองรับผู้ให้บริการขนส่งของพันธมิตร และตรวจสอบให้แน่ใจว่าหมายเลขติดตามถูกส่งเข้าสู่ระบบของคุณอย่างน่าเชื่อถือ
tracking API จะทำให้การสแกนของผู้ให้บริการขนส่งเกิดขึ้นเร็วขึ้นหรือไม่
ไม่สามารถสร้างการสแกนทางกายภาพของผู้ให้บริการขนส่งได้ แต่ช่วยให้แอปพลิเคชันของคุณเรียกดู จัดระเบียบ และเผยแพร่ข้อมูลที่แหล่งข้อมูลการติดตามจัดเตรียมไว้ได้ ควรประเมินพฤติกรรมการอัปเดตจากพัสดุจริง แทนที่จะสันนิษฐานว่า API รับประกันการมองเห็นทุกการเคลื่อนย้ายได้ทันที
ฉันต้องใช้ผู้ให้บริการ API สองรายเพื่อใช้ทั้งสองความสามารถหรือไม่
ไม่จำเป็น คุณต้องการฟังก์ชันทั้งสอง ไม่จำเป็นต้องใช้ผู้ให้บริการสองราย ใช้ผู้ให้บริการรายเดียวเมื่อรองรับข้อกำหนดด้านการจัดส่งและการติดตามของคุณ แยกผู้ให้บริการเมื่อการทำเช่นนั้นช่วยรักษาเวิร์กโฟลว์ที่ทำงานได้อยู่แล้ว หรือรองรับข้อกำหนดเฉพาะที่ตัวเลือกแบบรวมไม่สามารถตอบสนองได้
tracking API สามารถแทนที่ระบบจัดการคำสั่งซื้อได้หรือไม่
ไม่ได้ ข้อมูลการติดตามเป็นข้อมูลนำเข้าสำหรับการจัดการคำสั่งซื้อ ไม่ใช่สิ่งทดแทนการจัดสรรสินค้าคงคลัง การตัดสินใจด้านการจัดส่ง การจัดการการชำระเงิน หรือระเบียนคำสั่งซื้อ แอปพลิเคชันของคุณยังต้องเชื่อมโยงพัสดุแต่ละรายการกับคำสั่งซื้อที่ถูกต้อง และตัดสินใจว่าอีเวนต์การจัดส่งจะส่งผลต่อเวิร์กโฟลว์ทางธุรกิจอย่างไร
แหล่งข้อมูล
- เอกสาร FedEx Ship API — แหล่งอ้างอิงสำหรับการสร้างรายการจัดส่ง ใบปะหน้าพัสดุ และข้อกำหนดของเวิร์กโฟลว์การจัดส่ง
- เอกสาร FedEx tracking API — แหล่งอ้างอิงสำหรับคำขอติดตามและข้อมูลสถานะการจัดส่ง
- 17TRACK Tracking API — แหล่งอ้างอิงผลิตภัณฑ์อย่างเป็นทางการสำหรับหมวดหมู่การเชื่อมต่อด้านการติดตาม
- เอกสาร 17TRACK API — แหล่งอ้างอิงสำหรับการลงทะเบียนการติดตาม ข้อมูลการติดตาม และการเชื่อมต่อการแจ้งเตือนแบบพุช
