การผสานรวม Shopify API: วิธีการทำงาน กรณีการใช้งาน และการเริ่มต้นใช้งาน
A Shopify API integration เชื่อมต่อร้านค้ากับระบบอื่น เพื่อให้สินค้า คำสั่งซื้อ ลูกค้า ข้อมูลการจัดส่ง หรือเหตุการณ์การขนส่งสามารถถ่ายโอนระหว่างกันได้โดยไม่ต้องป้อนข้อมูลด้วยตนเองซ้ำ ๆ โดยทั่วไปการติดตั้งจะเริ่มจาก Shopify app หรือบริการปฏิบัติการภายใน ใช้สิทธิ์ API ที่เหมาะสม รับการเปลี่ยนแปลงผ่านเว็บฮุกเมื่อทำได้ และเพิ่มมาตรการป้องกันสำหรับการยืนยันตัวตน ขีดจำกัดอัตราการเรียกใช้ การลองใหม่ และเหตุการณ์ซ้ำ สำหรับการมองเห็นสถานะการขนส่ง สามารถพิจารณา tracking API เช่น 17TRACK API ร่วมกับข้อมูลคำสั่งซื้อและการจัดส่งของ Shopify ได้
การออกแบบ integration ที่เหมาะสมขึ้นอยู่กับกระบวนการทางธุรกิจที่ต้องการทำให้เป็นอัตโนมัติ ร้านค้าที่ต้องการเพียงหน้าติดตามพัสดุที่มีแบรนด์ จะมีความต้องการแตกต่างจากร้านค้าปลีกที่ซิงโครไนซ์ Shopify กับ ERP ระบบจัดการคลังสินค้า แพลตฟอร์มบริการลูกค้า หรือบริการติดตามพัสดุจากผู้ให้บริการขนส่งหลายราย
Shopify API integration ทำอะไรได้บ้าง
API integration ช่วยให้ระบบสองระบบแลกเปลี่ยนข้อมูลที่มีโครงสร้างผ่านคำขอที่ผ่านการยืนยันตัวตนและการแจ้งเตือนเหตุการณ์ ในกระบวนการอีคอมเมิร์ซทั่วไป Shopify ยังคงเป็นแหล่งข้อมูลหลักสำหรับข้อมูลการค้าในบางส่วน ขณะที่แพลตฟอร์มอื่นจัดการกระบวนการเฉพาะด้าน
- จาก Shopify ไปยังระบบอื่น: สามารถส่งคำสั่งซื้อ ข้อมูลสินค้า รายละเอียดลูกค้า บันทึกการจัดส่ง และเหตุการณ์คำสั่งซื้อที่เลือกไว้ไปยัง ERP แพลตฟอร์มคลังสินค้า ระบบวิเคราะห์ หรือเครื่องมือบริการลูกค้าได้
- จากระบบอื่นไปยัง Shopify: สามารถเขียนข้อมูลการอัปเดตสินค้าคงคลัง การยืนยันการจัดส่ง หมายเลขติดตาม และการเปลี่ยนแปลงสถานะการจัดส่งกลับไปยัง Shopify ได้ เมื่อ integration มีสิทธิ์ที่จำเป็นและกระบวนการปลายทางรองรับ
- เหตุการณ์ไปยังแอปพลิเคชัน: เว็บฮุกสามารถแจ้ง integration เมื่อเกิดการเปลี่ยนแปลงที่เลือกไว้ ช่วยลดความจำเป็นในการเรียกตรวจสอบ Shopify ซ้ำ ๆ สำหรับทุกการอัปเดตที่อาจเกิดขึ้น
- ข้อมูลการติดตามไปยังประสบการณ์ลูกค้า: เหตุการณ์จากผู้ให้บริการขนส่งสามารถถูกปรับให้อยู่ในรูปแบบมาตรฐานโดยบริการติดตาม แล้วแสดงในกระบวนการตรวจสอบสถานะคำสั่งซื้อ ระบบแจ้งเตือน หรืออินเทอร์เฟซสนับสนุนของร้านค้า
API ไม่ได้ตัดสินใจโดยอัตโนมัติว่าควรถ่ายโอนระเบียนใด ควรจับคู่ฟิลด์อย่างไร หรือควรทำอย่างไรเมื่อระบบไม่ตรงกัน สิ่งเหล่านี้เป็นการตัดสินใจด้านการออกแบบ integration ดังนั้นโครงการที่เชื่อถือได้จึงควรมีหลักเกณฑ์ทางธุรกิจ ความเป็นเจ้าของข้อมูล การตรวจสอบ และกระบวนการกู้คืน ไม่ใช่เพียงการเชื่อมต่อระหว่าง endpoint สองจุด
การทำงานของ integration
1. เลือกรูปแบบ integration
มีรูปแบบที่ใช้กันทั่วไปสามรูปแบบ
- Shopify app แบบเนทีฟ: แอปที่ผู้ค้าติดตั้งจะจัดการการอนุญาตและใช้ Shopify APIs เพื่อเข้าถึงข้อมูลร้านค้าที่ได้รับอนุญาต เหมาะสำหรับ integration ที่ให้บริการหลายร้านค้า
- แอปแบบกำหนดเองหรือบริการภายใน: ธุรกิจสร้าง integration สำหรับร้านค้าหรือองค์กรของตนเอง วิธีนี้ควบคุมการจับคู่ฟิลด์และกฎการปฏิบัติงานได้มากขึ้น แต่เจ้าของยังต้องจัดการข้อมูลรับรอง สิทธิ์ การเปลี่ยนเวอร์ชัน และความเสถียร
- แพลตฟอร์มตัวเชื่อมต่อหรือระบบอัตโนมัติ: ตัวเชื่อมต่อจากบุคคลที่สามเชื่อม Shopify กับบริการอื่นผ่าน workflow ที่สร้างไว้ล่วงหน้า ช่วยลดเวลาในการติดตั้งได้ แต่อาจต้องพัฒนาแบบกำหนดเองหากมีกฎการจัดส่งที่ซับซ้อน ปริมาณเหตุการณ์สูง หรือรูปแบบข้อมูลเฉพาะ
ก่อนเลือกรูปแบบ ให้จัดทำเอกสารเกี่ยวกับระบบที่เกี่ยวข้อง ระเบียนที่ต้องถ่ายโอน ทิศทางของการไหลของข้อมูลแต่ละรายการ และความล่าช้าที่ยอมรับได้ การอัปเดตการติดตามที่มาถึงภายในไม่กี่นาทีอาจเพียงพอสำหรับหน้าที่ลูกค้าเห็น ขณะที่การซิงโครไนซ์สินค้าคงคลังอาจต้องมีการควบคุมการปฏิบัติงานที่เข้มงวดกว่า
2. สร้างสิทธิ์เข้าถึงด้วยขอบเขตที่เล็กที่สุดเท่าที่ใช้งานได้
Shopify ใช้ขอบเขตการเข้าถึง API เพื่อควบคุมว่าแอปพลิเคชันสามารถอ่านหรือเขียนข้อมูลใดได้บ้าง integration ควรขอเฉพาะสิทธิ์ที่จำเป็นต่อฟังก์ชันที่ระบุไว้เท่านั้น ตัวอย่างเช่น บริการที่อ่านข้อมูลการจัดส่งไม่ควรขอสิทธิ์แก้ไขข้อมูลสินค้าหรือลูกค้าที่ไม่เกี่ยวข้องโดยอัตโนมัติ
รายละเอียดการยืนยันตัวตนขึ้นอยู่กับประเภทแอปและข้อกำหนดแพลตฟอร์มปัจจุบันของ Shopify ควรถือว่าเอกสารของ Shopify เป็นแหล่งข้อมูลหลักสำหรับขั้นตอนการอนุญาตที่รองรับ การจัดการโทเคน และ API เวอร์ชันปัจจุบัน ควรจัดเก็บข้อมูลรับรองร้านค้าในระบบจัดการความลับ แทนการเก็บไว้ในซอร์สโค้ด สเปรดชีต พื้นที่จัดเก็บของเบราว์เซอร์ หรือไฟล์การกำหนดค่าทั่วไป
3. เลือก API และโมเดลข้อมูล
Shopify มี API สำหรับวัตถุประสงค์ที่แตกต่างกัน Admin GraphQL API เป็นตัวเลือกหลักสำหรับข้อมูลร้านค้าเชิงการดูแลระบบ และช่วยให้แอปพลิเคชันร้องขอฟิลด์ผ่านโมเดลการสืบค้นแบบกราฟ Shopify ยังมีเอกสารเกี่ยวกับ API และอินเทอร์เฟซอื่นสำหรับกรณีใช้งานเฉพาะ ดังนั้นควรยืนยันตัวเลือกที่ถูกต้องกับเอกสารปัจจุบัน แทนการอ้างอิงจากบทเรียนเก่าโดยไม่ตรวจสอบ
งานออกแบบหลักคือการจับคู่วัตถุทางธุรกิจระหว่างระบบ ตัวอย่างเช่น คำสั่งซื้อ Shopify อาจตรงกับคำสั่งซื้อใน ERP คำขอจัดส่งในระบบคลังสินค้า และระเบียนการขนส่งในแพลตฟอร์มติดตาม วัตถุเหล่านี้อาจไม่มีตัวระบุหรือคำศัพท์สถานะเดียวกัน ควรจัดเก็บ ID ต้นฉบับจากแต่ละระบบและกำหนดการอ้างอิงข้ามระบบที่มั่นคง แทนการจับคู่ระเบียนด้วยชื่อของลูกค้าหรือยอดคำสั่งซื้อเพียงอย่างเดียว
4. ใช้เว็บฮุกร่วมกับการอ่าน API ที่มีการควบคุม
เว็บฮุกมีประโยชน์เมื่อระบบต้องตอบสนองต่อการเปลี่ยนแปลง สามารถเริ่ม workflow หลังเกิดเหตุการณ์ Shopify ที่เกี่ยวข้อง แทนการเรียกตรวจสอบอย่างต่อเนื่อง อย่างไรก็ตาม โดยทั่วไปควรถือว่าเว็บฮุกขาเข้าเป็นสัญญาณสำหรับตรวจสอบและประมวลผลการเปลี่ยนแปลง ไม่ใช่หลักฐานว่าการดำเนินการปลายทางทั้งหมดสำเร็จแล้ว
ตัวจัดการที่มีความแข็งแกร่งจะตรวจสอบคำขอตามวิธีที่ Shopify ระบุไว้ บันทึกเหตุการณ์ ตรวจสอบว่าเคยประมวลผลแล้วหรือไม่ และนำงานเข้า queue เมื่อการประมวลผลอาจใช้เวลา จากนั้น worker จะดึงระเบียนที่จำเป็น ใช้กฎทางธุรกิจ และบันทึกผลลัพธ์ วิธีนี้ช่วยป้องกัน timeout และทำให้การลองใหม่ปลอดภัยยิ่งขึ้น
5. จัดการขีดจำกัด ความล้มเหลว และการเปลี่ยนแปลงเวอร์ชัน
การเรียก API อาจล้มเหลวเนื่องจากปัญหาเครือข่ายชั่วคราว ข้อมูลรับรองหมดอายุ ข้อมูลไม่ถูกต้อง การเปลี่ยนแปลงสิทธิ์ การจำกัดอัตราการเรียกใช้ หรือการเปลี่ยนเวอร์ชัน API integration ควรแยกความล้มเหลวชั่วคราวออกจากข้อผิดพลาดด้านการตรวจสอบถาวร ความล้มเหลวชั่วคราวสามารถลองใหม่ด้วย backoff ส่วนข้อผิดพลาดถาวรต้องมีการแจ้งเตือน workflow แก้ไข หรือการตรวจสอบด้วยตนเอง
ขีดจำกัดอัตราการเรียกใช้เป็นส่วนหนึ่งของการออกแบบทางเทคนิค ไม่ใช่การปรับปรุงในขั้นสุดท้าย ควรใช้ pagination ร้องขอเฉพาะฟิลด์ที่จำเป็น หลีกเลี่ยงการ polling ที่ไม่จำเป็น จัดคิวคำขอจำนวนมาก และติดตามรหัสการตอบกลับกับเวลาแฝงในการประมวลผล ควรตรวจสอบขีดจำกัดและพฤติกรรมปัจจุบันของ Shopify จากเอกสารอย่างเป็นทางการก่อนประเมินความสามารถในการรองรับระบบจริง
กรณีใช้งานทั่วไปของ Shopify API integration
การซิงโครไนซ์คำสั่งซื้อและการจัดส่ง
integration ด้านการจัดส่งสามารถส่งคำสั่งซื้อใหม่ไปยังคลังสินค้าหรือ 3PL แล้วเขียนการยืนยันการจัดส่งและหมายเลขติดตามกลับไปยัง Shopify การตัดสินใจสำคัญคือคำสั่งซื้อมีสิทธิ์ส่งออกเมื่อใด จะจัดการคำสั่งซื้อที่ยกเลิกหรือแก้ไขอย่างไร และระบบใดเป็นเจ้าของสถานะการขนส่งหลังจากส่งต่อแล้ว
อย่าสมมติว่าการสร้างคำสั่งซื้อหมายความว่าพร้อมจัดส่งแล้ว สถานะการชำระเงิน การตรวจสอบการฉ้อโกง การจัดสรรสินค้าคงคลัง การตรวจสอบที่อยู่จัดส่ง และสถานที่จัดส่งอาจส่งผลต่อกฎการปล่อยคำสั่งซื้อทั้งหมด
การซิงโครไนซ์สินค้าคงคลัง
integration สินค้าคงคลังจะซิงโครไนซ์จำนวนสินค้าที่พร้อมขายระหว่าง Shopify คลังสินค้า marketplace และระบบภายใน การออกแบบที่ดีควรกำหนดแหล่งข้อมูลสินค้าคงคลัง สต็อกสำรอง พฤติกรรมการจอง และการแก้ไขข้อขัดแย้ง หากไม่มีกฎเหล่านี้ ระบบสองระบบอาจเขียนทับกันหรือแสดงสินค้าที่ถูกจัดสรรไปแล้ว
บริการลูกค้าและการค้นหาคำสั่งซื้อ
แพลตฟอร์มสนับสนุนสามารถใช้ข้อมูล Shopify เพื่อช่วยให้เจ้าหน้าที่ค้นหาคำสั่งซื้อ ตรวจสอบความคืบหน้าการจัดส่ง และระบุการดำเนินการถัดไป ลดการสลับแท็บได้ แต่ควรจำกัดข้อมูลลูกค้าให้เหมาะกับกรณีใช้งานด้านการสนับสนุน ควรทบทวนข้อกำหนดด้านการเก็บรักษา การควบคุมการเข้าถึง และความเป็นส่วนตัวก่อนคัดลอกข้อมูลส่วนบุคคลไปยังแพลตฟอร์มอื่น
การติดตามพัสดุและการอัปเดตหลังการซื้อ
Shopify สามารถจัดเก็บข้อมูลคำสั่งซื้อและการจัดส่ง ขณะที่บริการติดตามอาจให้เหตุการณ์การขนส่งเฉพาะผู้ให้บริการและมุมมองสถานะที่ปรับเป็นมาตรฐานแล้ว การแยกหน้าที่นี้มีประโยชน์เมื่อผู้ค้าทำงานกับผู้ให้บริการหลายรายหรือจัดส่งระหว่างประเทศ integration ควรจับคู่รหัสผู้ให้บริการ หมายเลขติดตาม ข้อมูลอ้างอิงการขนส่ง และสถานะเหตุการณ์อย่างสอดคล้องกัน
สำหรับผู้ค้าที่ต้องการ workflow การติดตามบน Shopify ที่พร้อมใช้งานแทนโครงการ API แบบกำหนดเอง สามารถพิจารณา 17TRACK Shopify app อย่างเป็นทางการเป็นตัวเลือกแยกต่างหาก สำหรับแอปพลิเคชันแบบกำหนดเอง ควรตรวจสอบ เอกสาร 17TRACK API เกี่ยวกับข้อกำหนดปัจจุบันด้านการยืนยันตัวตน endpoint การติดตาม และบัญชี แอปและ API แก้ปัญหาการติดตั้งที่เกี่ยวข้องกันแต่แตกต่างกัน ไม่ควรนำเสนอสิ่งหนึ่งเป็นตัวแทนของอีกสิ่งหนึ่งโดยไม่ทดสอบ workflow ที่ต้องการ
แผนเริ่มต้นใช้งานจริง
- เขียนผลลัพธ์ในแง่ธุรกิจ ตัวอย่างเช่น: “ส่งคำสั่งซื้อที่ชำระเงินแล้วไปยังคลังสินค้าภายในช่วงเวลาบริการที่กำหนด” หรือ “แสดงความคืบหน้าการขนส่งให้ลูกค้าหลังจากกำหนดหมายเลขติดตามแล้ว”
- ระบุระบบและเจ้าของ ระบุว่าใครเป็นเจ้าของสินค้า สินค้าคงคลัง คำสั่งซื้อ การจัดส่ง เหตุการณ์การติดตาม และการแจ้งเตือนลูกค้า
- สร้างแผนผังฟิลด์ รวม ID เวลาประทับ ค่า status ที่อยู่ จำนวน รหัสผู้ให้บริการ หมายเลขติดตาม และฟิลด์ข้อผิดพลาด ระบุฟิลด์ที่จำเป็น ไม่บังคับ อ่านอย่างเดียว และถูกแปลงค่า
- ยืนยันเอกสารปัจจุบัน ตรวจสอบ API version วิธีการยืนยันตัวตน access scopes ข้อกำหนดเว็บฮุก พฤติกรรม pagination และ rate limits ของ Shopify ตรวจสอบเอกสารที่เกี่ยวข้องของทุกแพลตฟอร์มภายนอก
- สร้าง proof of concept ที่จำกัดขอบเขต เริ่มจากร้านค้าทดสอบขนาดเล็กหรือชุดข้อมูลที่ควบคุมได้ พิสูจน์การยืนยันตัวตน เส้นทางการอ่านหนึ่งเส้นทาง เส้นทางการเขียนหนึ่งเส้นทางหากจำเป็น และ workflow ที่ขับเคลื่อนด้วยเหตุการณ์หนึ่งรายการ ก่อนเพิ่มประเภทวัตถุทั้งหมด
- เพิ่ม idempotency และ reconciliation เว็บฮุกหรือการลองใหม่ซ้ำต้องไม่สร้างการจัดส่ง ข้อความลูกค้า หรือการปรับสินค้าคงคลังซ้ำ ควรกำหนดเวลาตรวจสอบ reconciliation เพื่อค้นหาระเบียนที่ตกหล่นหรือถูกปฏิเสธ
- ทดสอบข้อยกเว้นด้านการปฏิบัติงาน รวมคำสั่งซื้อที่ยกเลิก ที่อยู่ที่แก้ไข การจัดส่งแยกส่วน การจัดส่งบางส่วน หมายเลขติดตามที่หายไป รหัสผู้ให้บริการไม่ถูกต้อง เหตุการณ์ซ้ำ การจำกัด API ข้อมูลรับรองหมดอายุ และการอัปเดตจากผู้ให้บริการขนส่งที่ล่าช้า
- เปิดใช้งานพร้อมการตรวจสอบ ติดตามเหตุการณ์ที่สำเร็จและล้มเหลว อายุของ queue ข้อผิดพลาดการตอบกลับ API เวลาในการประมวลผล และระเบียนที่ต้องดำเนินการด้วยตนเอง กำหนดผู้รับการแจ้งเตือนและวิธี replay ความล้มเหลว
ควรใช้ connector, custom app หรือ tracking API เมื่อใด
| ตัวเลือก | มักเหมาะกับ | สิ่งที่ต้องตรวจสอบก่อนเลือก |
|---|---|---|
| เครื่องมือ connector หรือ automation | workflow มาตรฐานที่ปรับแต่งได้จำกัด | วัตถุที่รองรับ ความล่าช้าของเหตุการณ์ การจัดการข้อผิดพลาด ขีดจำกัดงาน และการเก็บรักษาข้อมูล |
| Shopify app หรือ service แบบกำหนดเอง | กฎทางธุรกิจเฉพาะ ระบบหลายระบบ หรือกระบวนการภายในที่ควบคุมได้ | เจ้าของการพัฒนา ความปลอดภัย การตรวจสอบ การบำรุงรักษา API และต้นทุนการดำเนินงานทั้งหมด |
| Tracking API | ประสบการณ์หลังการซื้อหรือการมองเห็นสถานะการขนส่งแบบกำหนดเอง | ข้อกำหนดของผู้ให้บริการและภูมิภาค วงจรชีวิตการติดตาม พฤติกรรมการอัปเดต ขีดจำกัด และเงื่อนไขทางการค้า |
Connector ไม่ได้ง่ายกว่าโดยอัตโนมัติ หาก workflow ต้องใช้การลองใหม่แบบกำหนดเองหรือ reconciliation ที่ซับซ้อน ในทางกลับกัน integration แบบกำหนดเองก็ไม่ได้ดีกว่าโดยอัตโนมัติ หากแอปมาตรฐานที่รองรับอย่างดีตอบโจทย์ได้แล้ว ตัวเลือกที่เหมาะสมที่สุดคือการติดตั้งที่มีขนาดเล็กที่สุดและยังตอบสนองข้อกำหนดด้านข้อมูล ความน่าเชื่อถือ ความปลอดภัย และการปฏิบัติงาน
เช็กลิสต์ด้านความปลอดภัยและความน่าเชื่อถือ
- ใช้ access scopes ตามหลักสิทธิ์น้อยที่สุดและทบทวนเมื่อ integration เปลี่ยนแปลง
- เก็บโทเคนและความลับไว้นอกโค้ดแอปพลิเคชัน และหมุนเวียนผ่านกระบวนการที่ควบคุม
- ตรวจสอบความถูกต้องของเว็บฮุกตามเอกสารของแพลตฟอร์ม
- เข้ารหัสข้อมูลระหว่างส่งและจำกัดการเข้าถึงเชิงผู้ดูแลระบบต่อ log และระเบียนลูกค้า
- ใช้การประมวลผลแบบ idempotent เพื่อให้การลองใหม่ไม่ทำให้ผลข้างเคียงเกิดซ้ำ
- จัดเก็บ ID ของระบบต้นทางและเวลาของเหตุการณ์เพื่อการตรวจสอบและ reconciliation
- แยกข้อมูลรับรองสำหรับการทดสอบและระบบจริง และหลีกเลี่ยงการใช้ข้อมูลลูกค้าจริงในการทดสอบทั่วไป
- ทบทวนข้อผูกพันด้านความเป็นส่วนตัว การเก็บรักษา และการลบ ก่อนคัดลอกข้อมูลส่วนบุคคลไปยังบริการอื่น
- ติดตาม API version และวางแผนอัปเกรดก่อนเวอร์ชันที่รองรับมีการเปลี่ยนแปลง
คำถามที่พบบ่อย
Shopify API integration เหมือนกับการติดตั้ง Shopify app หรือไม่?
ไม่เหมือนกัน Shopify app อาจใช้ Shopify APIs แต่การติดตั้งแอปเป็นการดำเนินการติดตั้งที่ผู้ค้าเห็นโดยตรง ส่วน API integration คือการเชื่อมต่อในภาพรวมระหว่าง Shopify กับระบบอื่น ซึ่งอาจให้บริการผ่านแอปสาธารณะ แอปแบบกำหนดเอง บริการภายใน หรือตัวเชื่อมต่อ
ควรใช้ Shopify API ใด?
เลือก API ตามข้อมูลและ workflow จากนั้นยืนยันคำแนะนำปัจจุบันในเอกสารของ Shopify สำหรับข้อมูลร้านค้าเชิงการดูแลระบบ Admin GraphQL API เป็นตัวเลือกทั่วไป แต่ต้องตรวจสอบการยืนยันตัวตน สิทธิ์ ความพร้อมใช้งานของวัตถุ และการรองรับเวอร์ชันสำหรับกรณีใช้งานที่แน่นอน
Shopify สามารถให้ข้อมูลอัปเดตการติดตามจากผู้ให้บริการขนส่งได้เองหรือไม่?
Shopify สามารถจัดเก็บข้อมูลการจัดส่งและการติดตามได้ แต่ประสบการณ์การติดตามทั้งหมดขึ้นอยู่กับแหล่งที่มาของเหตุการณ์การขนส่ง การปรับให้อยู่ในรูปแบบมาตรฐาน การแสดงผล และการสื่อสาร หากเป็น workflow ที่มีผู้ให้บริการหลายรายหรือการขนส่งระหว่างประเทศ อาจต้องใช้บริการติดตามเฉพาะหรือ integration layer อื่น
ควรใช้เว็บฮุกหรือ polling?
โดยทั่วไปเว็บฮุกเหมาะสำหรับตอบสนองต่อการเปลี่ยนแปลง ขณะที่การอ่าน API ที่มีการควบคุมเหมาะสำหรับการตรวจสอบ reconciliation และการกู้คืน integration สำหรับระบบจริงมักใช้ทั้งสองวิธี แทนการพึ่งพาวิธีใดวิธีหนึ่งเพียงอย่างเดียว
Shopify API integration ใช้เวลานานเท่าใด?
ไม่มีระยะเวลาเดียวที่เชื่อถือได้ Connector พื้นฐานอาจตั้งค่าได้รวดเร็ว ขณะที่ integration แบบกำหนดเองซึ่งเกี่ยวข้องกับสินค้าคงคลัง การจัดส่ง ข้อมูลลูกค้า ผู้ให้บริการหลายราย และ reconciliation ต้องใช้การออกแบบและการทดสอบมากกว่า จำนวนระบบ กฎข้อยกเว้น การตรวจสอบความปลอดภัย และการควบคุมการนำไปใช้งาน เป็นตัวชี้วัดที่ดีกว่าการเชื่อมต่อ Shopify เพียงอย่างเดียว
