Yehonatan Saadia logo
Shopify או WooCommerce מחזירים 429: כך בונים סנכרון שלא נחסם
חזרה לבלוג
full stack·5 בספטמבר 2026·4 דק' קריאה·מאת יהונתן סעדיה

Shopify או WooCommerce מחזירים 429: כך בונים סנכרון שלא נחסם

429 בשופיפיי מגיע עם Retry-After ועם דלי בגודל 40 בקשות; ב-WooCommerce המקור הוא בכלל האחסון. איך קוראים את הכותרות ובונים סנכרון שממשיך לעבוד.

עיקרי הדברים

  • שופיפיי מפרסמת את המגבלות: דלי של 40 בקשות עם דליפה של 2 בשנייה בתוכנית הרגילה, ופי עשרה מכך ב-Shopify Plus.
  • כל תשובת REST מכילה `X-Shopify-Shop-Api-Call-Limit` בפורמט `32/40`, כלומר יש לכם מד דלק בכל בקשה.
  • ב-GraphQL המודל שונה לגמרי: תקציב נקודות לשנייה, ושאילתה בודדת אינה יכולה לעלות יותר מ-1,000 נקודות.
  • WooCommerce עצמו אינו מגביל את ה-REST API. 429 שמגיע ממנו שייך לשרת, ל-CDN או לתוסף אבטחה.
  • סנכרון שנשען על לולאה עם `sleep` קבוע ייכשל ברגע שמישהו אחר יעבוד מול אותה חנות.

429 בשופיפיי הוא מנגנון מתועד: ה-REST Admin API עובד לפי דלי דולף בגודל 40 בקשות לאפליקציה לחנות בתוכניות הרגילות, ותשובת 429 מגיעה עם כותרת Retry-After שאומרת כמה שניות להמתין. ב-WooCommerce המצב הפוך - הליבה אינה מגבילה קצב, ולכן 429 מגיע כמעט תמיד מהאחסון או מ-WAF.

שני מודלים שונים באותה פלטפורמה

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

REST Admin APIGraphQL Admin API
היחידה הנמדדתבקשהעלות מחושבת בנקודות
התקציב בתוכנית הרגילהדלי של 40 בקשות100 נקודות לשנייה
קצב ההתאוששות2 בקשות בשנייהמילוי מחדש שוטף לפי restoreRate
איפה רואים את המצבכותרת X-Shopify-Shop-Api-Call-Limitextensions.cost.throttleStatus בגוף התשובה
מה קורה בחריגה429 עם Retry-Afterהשאילתה נחנקת והתקציב מוצג בתשובה
תקרה נוספתאיןשאילתה בודדת עד 1,000 נקודות

ההבדל המעשי: ב-REST הבקשה היא היחידה, ולכן משיכה של 500 מוצרים אחד-אחד תמצה את הדלי גם אם כל בקשה זעירה. ב-GraphQL העלות נגזרת מכמות השדות והחיבורים שביקשתם, ולכן שאילתה אחת רחבה מדי יכולה לחרוג לבדה.

למה WooCommerce מחזיר 429 אם אין לו הגבלת קצב?

כי ההגבלה אינה באה מ-WooCommerce. חנות WooCommerce רצה על WordPress, שרץ על שרת אינטרנט, שיושב לרוב מאחורי שכבת הגנה. כל אחת מהשכבות האלה יכולה להחזיר 429, ואף אחת מהן אינה מכירה את הלוגיקה של החנות.

  • האחסון. כללי הגבלה ברמת Nginx או Apache על נתיבי wp-json ועל admin-ajax.php.
  • תוסף אבטחה או WAF. חסימות שמופעלות על נתיבים ספציפיים, לעיתים בלי כותרת Retry-After בכלל.
  • Store API. זו השכבה היחידה שבה WooCommerce כן מתעדת הגבלת קצב משלה - ברירת מחדל של 25 בקשות בחלון של 10 שניות, על בקשות POST בלבד, וכבויה כברירת מחדל. היא מחזירה כותרות RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset ו-RateLimit-Retry-After.

לכן האבחון ב-WooCommerce מתחיל בשאלה אחרת לגמרי: לא "איך מאטים את הסנכרון" אלא "מי החזיר את ה-429". ההבדל נראה בגוף התשובה - שגיאת WordPress מובנית נראית אחרת לחלוטין מדף חסימה של WAF.

איך קוראים את המצב במקום לנחש

  • ב-REST של שופיפיי, קראו את X-Shopify-Shop-Api-Call-Limit בכל תשובה. הערך 38/40 אומר שנשארו שתי בקשות, ואפשר להאט לפני שנחסמים במקום אחרי.
  • כשמגיע 429, כבדו את Retry-After כפי שהוא. זה מספר השניות שהפלטפורמה עצמה מבקשת להמתין, והוא מדויק יותר מכל נוסחה שתמציאו.
  • ב-GraphQL, קראו את throttleStatus בכל תשובה: maximumAvailable, currentlyAvailable ו-restoreRate נותנים תמונת תקציב מלאה.
  • שמרו את requestedQueryCost מול actualQueryCost. פער גדול ביניהם אומר שאתם מבקשים דפים גדולים מדי ומקבלים פחות.
  • ב-WooCommerce, רשמו את קוד הסטטוס יחד עם גוף התשובה הגולמי ועם כל הכותרות. בלי זה אי אפשר להבדיל בין חסימת שרת לבין הגבלה של Store API.

איך בונים סנכרון ששורד 429?

  1. הפרידו בין איסוף לעיבוד. תהליך אחד מושך ורושם לתור, תהליך אחר צורך מהתור. סנכרון שעושה את שניהם בלולאה אחת נעצר כולו כשמגיע 429.
  2. תנו לכל פריט בתור מונה ניסיונות וזמן ניסיון הבא. Retry-After נכתב אל תוך זמן הניסיון הבא, לא אל תוך sleep שחוסם את כל התהליך.
  3. עבדו עם עובד יחיד לכל חנות. הדלי בשופיפיי הוא לכל אפליקציה לכל חנות, ולכן שני עובדים מקבילים מתחלקים באותו תקציב ומאיצים את החסימה.
  4. השתמשו בעימוד מבוסס סמן ושמרו את הסמן. סנכרון שמתחיל מההתחלה אחרי כל כישלון יבזבז את התקציב בדיוק על מה שכבר נמשך.
  5. עשו את הכתיבות אידמפוטנטיות. אחרי 429 אינכם יודעים אם הבקשה נחסמה לפני העדכון או אחריו, ובלי מפתח ייחודי לכל פעולה תיווצרנה כפילויות.
  6. תעדו קצב בפועל, לא קצב מתוכנן. מספר הבקשות שיצאו בפועל בדקה הוא המדד היחיד שמאפשר לכוונן.

מה נשבר בפועל

  • sleep קבוע. עובד לבד, נכשל ברגע שאפליקציה נוספת או משתמש בממשק הניהול צורכים מאותו דלי.
  • התעלמות מ-Retry-After. ניסיון חוזר מיידי מאריך את החסימה במקום לקצר אותה.
  • ריצה מקבילית "כדי לזרז". מכפילה את קצב הצריכה ומגיעה ל-429 מהר יותר, בלי להשלים יותר עבודה.
  • שאילתת GraphQL אחת ענקית. נכשלת על תקרת 1,000 הנקודות ולא על התקציב לשנייה, ולכן האטה לא תעזור לה.
  • טיפול ב-429 כשגיאה קטלנית. התהליך נופל, מישהו מריץ אותו מחדש מההתחלה, והמעגל נסגר.
  • סנכרון של הכול בכל הרצה. משיכה מלאה במקום שינויים מאז חותמת הזמן האחרונה היא הדרך המהירה ביותר למצות תקציב.

אבחון בחמש דקות כשהסנכרון נתקע

  1. הוציאו מהלוג את קוד הסטטוס המלא ואת כל כותרות התשובה של הבקשה שנכשלה. בלי הכותרות אין אבחון.
  2. ב-Shopify, בדקו את הערך של X-Shopify-Shop-Api-Call-Limit בבקשות שקדמו לכישלון. אם הוא כבר היה קרוב לתקרה, מדובר בקצב ולא בבאג.
  3. בדקו אם Retry-After קיים בכלל. קיומו מעיד על מגבלה מוצהרת של הפלטפורמה; היעדרו מרמז על חסימה של שכבת תשתית.
  4. ספרו כמה בקשות יצאו בפועל בדקה שקדמה לכישלון. המספר הזה, ולא הכוונה שבקוד, הוא מה שהפלטפורמה מדדה.
  5. בדקו מי עוד עובד מול אותה חנות באותו זמן - אפליקציה נוספת, עובד שני, או משתמש שמייצא נתונים מממשק הניהול.
  6. אם מדובר ב-GraphQL, השוו את requestedQueryCost ל-actualQueryCost בבקשות האחרונות שהצליחו. עלות מבוקשת גבוהה היא סימן לדפים גדולים מדי.

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

קשור: מה זו הגבלת קצב ב-API, Shopify מול WooCommerce, חיבור חנות מקוונת ל-ERP.

מקורות

#Shopify#WooCommerce#429 error#rate limits#inventory sync#שגיאות

שאלות נפוצות

כמה בקשות מותרות לי בשופיפיי?

ב-REST Admin API התקציב בתוכניות הרגילות הוא דלי של 40 בקשות לאפליקציה לחנות, שמתמלא בקצב של 2 בקשות בשנייה. ב-Shopify Plus הערכים גדולים פי עשרה. ב-GraphQL המדידה היא בנקודות ולא בבקשות, ולכן המספר תלוי בשאילתה עצמה.

האם שופיפיי מחזירה Retry-After?

כן. תשובת 429 ב-REST Admin API מוחזרת יחד עם כותרת `Retry-After` שמכילה את מספר השניות להמתנה. זה הערך שצריך לכבד, ולא לוח זמנים שקבעתם מראש. ב-GraphQL המידע מגיע במקום זאת בתוך `extensions.cost.throttleStatus`.

קיבלתי 429 מ-WooCommerce. מה לבדוק ראשון?

מי החזיר אותו. ליבת WooCommerce אינה מגבילה את ה-REST API, ולכן בדקו את לוגי שרת האינטרנט, את כללי ה-WAF או ה-CDN, ואת תוספי האבטחה. אם החסימה מגיעה מנתיב checkout, בדקו גם אם הגבלת הקצב של Store API הופעלה.

אפשר להעלות את המגבלה?

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

להמשך קריאה

full stack

WooCommerce או Shopify בישראל: בחירה לפי תפעול, תוכן, סליקה ובעלות

full stack

שגיאת 401 או 403 במורנינג (Green Invoice): מה ההבדל ואיך מתקנים

full stack

קודי דחייה של Cardcom ו-Tranzila: איך מתרגמים תשובת סליקה לפעולה נכונה

שירות רלוונטי

מלאי ורכש

מלאי ברמת SKU, כללי הזמנה חוזרת ותהליך אישור מתועד.

מידע נוסף →←

על הכותב

יהונתן סעדיה

מפתח פרילנסר לאוטומציה, אתרים ו-MVP

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

בוא נעבוד יחד

יש לך פרויקט דומה?

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

קביעת שיחהצור קשר