Shopify API 2026-10 מחייבת בדיקות של משלוחים, מלאי והזמנות

גרסת 2026-10 של ה-API של Shopify הפכה לגרסה היציבה ב-1 באוקטובר 2026. בחנויות שמאמצות אותה, בקשת אינטגרציה שהצליחה אינה מספיקה תמיד כדי להוכיח שהתקבלה התוצאה הרצויה: רישום שירות של חברת שילוח כבר אינו מוסיף את התעריפים שלו לפרופיל המשלוחים הכללי, לדברי Shopify.

הערות הגרסה הרשמיות מתארות גם שינויים בשגיאות מלאי, במיסוי הזמנות, בסטטוסים של מימוש הזמנות ובסינון לפי שדות מטא. סדר העדיפויות המעשי של ClickSyrup הוא לבדוק תחילה את הגדרת תעריפי השילוח ואת הטיפול הישן בשגיאת המלאי, ואז לבדוק עדכוני הזמנות ושאילתות מסוננות. זהו סדר בדיקות שהמערכת מציעה, לא דירוג שנמדד של תקלות בחנויות Shopify.

מתחילים בתעריפי השילוח ובטיפול במלאי

Shopify אומרת שיצירת שירות של חברת שילוח כעת רק רושמת את השירות. כדי שהתעריפים שמחשבת חברת השילוח יוכלו להופיע בקופה, צריך להגדיר אותם בפרופיל משלוחים. לכן סוכנות צריכה לבקש שתי בדיקות נפרדות: אישור שהשירות קיים, ואישור שהתעריפים הצפויים מופיעים בבדיקת קופה מתאימה.

ההבחנה חשובה, משום שבדיקה של תשובת היצירה בלבד עלולה להחמיץ את ההגדרה החסרה. אין להניח שהגרסה מסירה תעריפים קיימים או משפיעה על כל החנויות באותו אופן. השינוי המתועד עוסק במה שקורה בעת יצירת שירות של חברת שילוח.

בתחום המלאי, Shopify הסירה את ITEM_NOT_STOCKED_AT_LOCATION מפעולות המוטציה להתאמה, להעברה ולהגדרה של הכמות במלאי, וגם מטיפוס המנייה של שגיאות המשתמש. ההנחיה שלה היא להסיר את הלוגיקה באפליקציה שמטפלת בשגיאה המסוימת הזו.

יש לחפש באינטגרציה את המזהה המדויק, לרבות בענפים שמפעילים התרעות או פעולות התאוששות. לאחר מכן יש לבדוק את מסלולי ההצלחה והשגיאה שנותרו. היעלמות השגיאה הזו היא סיבה לעדכן הנחות, לא הוכחה שעדכוני מלאי נכשלים כעת ללא הודעה או שאפשר להתעלם מכל שגיאות המלאי.

שינויי הזמנות מחייבים סכומים מעודכנים וסטטוס חדש

שינוי כתובת המשלוח בהזמנה שטרם מומשה גורם כעת לחישוב מחדש של המסים לפי היעד החדש, לדברי Shopify. אחרי העדכון יש לשלוף מחדש את taxLines ואת totalTaxSet, ואז להתאים את היתרות לתשלום או להחזר שנוצרו בעקבותיו. יש להתייחס לעריכת הכתובת ולבדיקה הכספית כאל משימה תפעולית אחת.

לבעלי חנויות, השאלה המועילה היא אם האינטגרציה קוראת את הסכומים המעודכנים לפני שהיא מציגה את התוצאה ללקוח או לעובד. בקשו ממי שמתחזק אותה להדגים את הרצף באמצעות הזמנת בדיקה מתאימה, במקום להסתמך על שמירת הכתובת כסימן היחיד להצלחה.

Shopify אומרת גם ש-Order.displayFulfillmentStatus יכול להחזיר FULFILLMENT_NOT_REQUIRED במקום UNFULFILLED כאשר לא נותר בהזמנה דבר למימוש. קוד שממפה את הסטטוסים באופן ממצה חייב לכלול את הערך החדש. יש לבדוק כיצד הוא מוצג ולאיזה תהליך הוא מופנה, בלי להניח שמשמעותו זהה לסטטוס אחר.

מסנני שדות מטא חושפים כעת הנחות לא תקינות

שאילתה שמשתמשת בשדה מטא שאינו מוגדר לסינון מחזירה כעת שגיאה, במקום להתעלם מהמסנן ללא הודעה, לדברי Shopify. יש לבדוק שההגדרות של שדות המטא הרלוונטיים תומכות בסינון ובאופרטורים להשוואה שבהם משתמשת השאילתה.

כאן השינוי דווקא הופך שאילתה לא תקינה לגלויה יותר. יש לכלול בבדיקות מקרים של מסננים תקינים ולא תקינים, ולבדוק כיצד האפליקציה מציגה שגיאה במקום התוצאה המצופה. אין לתאר את ההתנהגות הזו ככשל שקט חדש.

לפני אימוץ הגרסה, בקשו ממי שמתחזק את האינטגרציה לתעד את התוצאות שנבדקו בכל ארבעת התחומים: משלוחים, מלאי, הזמנות וסינון. המדריך שלנו למסירת מוצרים דיגיטליים ב-Shopify הוא קריאה משלימה לחנויות שמוכרות הורדות או גישה. מסירה שימושית של העבודה צריכה להראות מה יראו הלקוח והמפעיל, לצד תשובת ה-API שהובילה לתוצאה הזו.