לעתים קרובות אנו נתקלים בתרחיש הבא: האינטגרציה עובדת, הנתונים מסונכרנים — ואז בערב יום שישי סקריפט מתחיל לשלוח בקשות בלולאה אינסופית, חורג מהמגבלה, מקבל שגיאת QUERY_LIMIT_EXCEEDED, וקורס. או גרוע מכך — הוא לא קורס אלא מיד מנסה שוב, ומחמיר את המצב. ל-API של Bitrix24 יש מגבלות קצב קפדניות, וכל אינטגרציה חייבת לקחת אותן בחשבון. אחרת — אובדן נתונים, חוסר סנכרון, חסימת יישום. הניסיון שלנו מראה: הגדרה נכונה של מגבלות קצב חוסכת שעות של ניפוי שגיאות ומונעת תקלות. לצוות שלנו יש ניסיון של 10+ שנים בפיתוח על Bitrix24 וביצענו מעל 50 אינטגרציות, כך שאנו מכירים את כל המלכודות. מאמר זה מכסה את מגבלות REST API של Bitrix24, שיטות אופטימיזציה ותרחישים ספציפיים שאנו מיישמים עבור לקוחות. תלמדו כיצד להימנע מטעויות אופייניות ולבנות אינטגרציה עמידה.
סקירת מגבלות API של Bitrix24
Bitrix24 מחיל מגבלות בשתי רמות:
| סוג | מגבלה | הערה |
|---|---|---|
| Webhooks (נכנסים) | 2 בקשות בשנייה | לכל webhook |
| יישומי שרת (OAuth) | 2 בקשות בשנייה | לכל יישום לכל פורטל |
| מגבלה יומית | 10,000 בקשות ביום | לתוכניות חינמיות. מסחריות — גבוה יותר |
| בקשת batch | 50 פקודות לכל batch | נספרת כבקשת API אחת |
לפי תיעוד REST API של Bitrix24, מגבלת השנייה היא 2 בקשות. כאשר המגבלה נחצית, ה-API מחזיר HTTP 503 עם גוף {"error":"QUERY_LIMIT_EXCEEDED"}. מומלץ לנסות שוב לאחר 500ms — לא מיד. המגבלה היומית מתאפסת בשעה 00:00 לפי שעון הפורטל. עבור יישומי marketplace, המגבלות שונות ותלויות במנוי המפתח.
שימוש בשיטת batch לעקיפת מגבלות
batch הוא הכלי המרכזי לחיסכון בבקשות. קריאה אחת של batch מכילה עד 50 פקודות ונספרת כבקשה אחת:
POST https://your-domain.bitrix24.by/rest/batch/ cmd[0]=crm.deal.list?filter[STAGE_ID]=WON cmd[1]=crm.deal.list?filter[STAGE_ID]=LOSE cmd[2]=crm.contact.list?filter[TYPE_ID]=CLIENT פקודות בתוך batch רצות ברצף. ניתן להשתמש בתוצאות של פקודות קודמות דרך POST https://your-domain.bitrix24.by/rest/batch/ cmd[0]=crm.deal.list?filter[STAGE_ID]=WON cmd[1]=crm.deal.list?filter[STAGE_ID]=LOSE cmd[2]=crm.contact.list?filter[TYPE_ID]=CLIENT :
cmd[0]=crm.deal.get?id=123 cmd[1]=crm.contact.get?id=$result[0][CONTACT_ID] שימוש בבקשות batch יעיל פי 50 מקריאות בודדות. במקום 50 בקשות נפרדות (25 שניות ב-2 בקשות/שנייה) — בקשה אחת ב-1-2 שניות.
מהי אסטרטגיית מגבלת הקצב הטובה ביותר עבור האינטגרציה שלך?
השוואה של אסטרטגיות ניהול מגבלות עוזרת לבחור את הגישה הנכונה. בקשות batch יעילות פי 50 מקריאות בודדות והן האופטימיזציה המשפיעה ביותר.
| אסטרטגיה | מורכבות | אמינות | התאמה |
|---|---|---|---|
| Exponential backoff | נמוכה | בינונית | תרחישים פשוטים |
| תור בקשות | בינונית | גבוהה | עומס גבוה |
| Token bucket | גבוהה | גבוהה | מערכות מבוזרות |
Exponential backoff — בעת קבלת $result, נסו שוב עם עיכוב הולך וגדל: 500ms → 1s → 2s → 4s. מקסימום 5 ניסיונות, ולאחר מכן רישום שגיאה.
תור בקשות — במקום קריאות API ישירות, הבקשות מוכנסות לתור (Redis, RabbitMQ, DB). עובד (worker) מעבד את התור, תוך כיבוד מרווח של 500ms בין בקשות. זה מבטל מצב שבו שני תהליכים שולחים בקשות בו-זמנית וחורגים יחד מהמגבלה.
Token bucket — מונה תוכנתי: היישום עוקב אחר מספר הבקשות בשנייה האחרונה וחוסם שליחה עד שחרור משבצת. מיושם דרך מצב משותף (Redis) עבור מערכות מבוזרות.
כמו כן, השתמשו בהפרדת זמנים: סנכרונים כבדים (ייצוא מלא של עסקאות, עדכון קטלוג) רצים בלילה כאשר משתמשים אינם משתמשים ב-API.
בחירת אסטרטגיית ניהול מגבלות
בחירת האסטרטגיה תלויה בעומס ובארכיטקטורה. עבור תרחישים פשוטים, exponential backoff מספיק — הוא אינו דורש שירותים נוספים. אם האינטגרציה בעומס גבוה (יותר מ-10 בקשות בשנייה בסך הכל), השתמשו בתור בקשות על Redis — הוא מבטיח עמידה במגבלות גם עם בקשות במקביל. Token bucket מתאים למערכות מבוזרות שבהן מספר microservices ניגשים לפורטל אחד.
כיצד לבדוק את השימוש הנוכחי ב-API?
ניתן לבדוק את השימוש הנוכחי בקריאות API באמצעות שיטת `app.info` — היא מחזירה את מספר הבקשות שנותרו לתקופה הנוכחית. עבור webhooks אין מדד דומה — יש לספור בצד שלכם. ביומני B24 (הגדרות → יומן אירועים) נרשמות שגיאות API כולל חריגות ממגבלות. אנו מגדירים התראה ב-80% מהמגבלה היומית.הימנעות משגיאת QUERY_LIMIT_EXCEEDED
יישום מגבלות קצב נכונות ב-Bitrix24 עוזר להימנע משגיאות QUERY_LIMIT_EXCEEDED ולמטב את השימוש במגבלות API. הימנעות משגיאות אלה יכולה לחסוך כ-$2,000 לכל תקרית באובדן פרודוקטיביות וזמן ניפוי שגיאות.
מדריך יישום שלב-אחר-שלב
- נתחו את דפוס הבקשות של האינטגרציה שלכם.
- קבצו פעולות לבקשות batch באמצעות שיטת
cmd[0]=crm.deal.get?id=123 cmd[1]=crm.contact.get?id=$result[0][CONTACT_ID]. - יישמו לוגיקת ניסיון חוזר עם exponential backoff ומקסימום 5 ניסיונות.
- הגדירו ניטור והתראות ב-80% מהמגבלה היומית.
- בצעו בדיקות עומס כדי לוודא עמידה במגבלות.
מה כלול בעבודת אופטימיזציית האינטגרציה שלנו
- ארכיטקטורת אינטגרציה בהתחשב במגבלות קצב: בקשות batch, תורים, backoff
- עובד (worker) לעיבוד רציף של בקשות API עם בקרת מהירות
- מעבר מבקשות בודדות ל-batch עבור פעולות המוניות
- ניטור שימוש במגבלות API והתראות בעת התקרבות לספים
- חלוקת עומס: סנכרונים ברקע בשעות לא-שיא
- אבחון ותיקון שגיאות
QUERY_LIMIT_EXCEEDED - תיעוד האינטגרציה המוגדרת
- גישה ללוחות ניטור והדרכה לצוות שלכם
- הגדרת מגבלות webhooks ויישומי OAuth
- בדיקות ביצועים ודוח אופטימיזציה
הערכת הפרויקט היא בחינם. אם אתם נתקלים בשגיאות QUERY_LIMIT_EXCEEDED או רוצים למטב את אינטגרציית ה-API שלכם, צרו קשר. המומחים המוסמכים שלנו בעלי ניסיון רב שנים עם Bitrix24 ומבטיחים את יציבות האינטגרציות שלכם. קבלו ייעוץ — נעזור לחסל צווארי בקבוק ולמנוע השבתות.