# מגבלות קצב

## המגבלה

כל מפתח API מוגבל ל-**60 בקשות בחלון של 60 שניות**. החלון נפתח עם הבקשה הראשונה ומתאפס 60 שניות אחריה. המגבלה היא לכל מפתח בנפרד, ולא לארגון. כל בקשה מאומתת נספרת, גם כזו שנכשלת ב-`4xx`; בקשה שנדחית ב-`401` לא נספרת.

בקשה שחורגת מהמגבלה מקבלת `429 Too Many Requests` ולא מבוצעת:

```json
{
  "retry_after": "2026-10-14T09:31:00.482913+00:00",
  "error": "Too Many Requests",
  "details": "Rate limit exceeded (61 requests in window)",
  "status": 429
}
```

`retry_after` הוא המועד שבו נפתח החלון הבא. התגובה כוללת גם את הכותרת התקנית `Retry-After` עם מספר השניות להמתנה.

## איך לעמוד במגבלה

- **עמודים גדולים** - בשליפת רשימות השתמשו ב-`limit=500`. עמוד של 500 רשומות עולה בקשה אחת, בדיוק כמו עמוד של 50.
- **סנכרון של חדשים בלבד** - הרשימות ממוינות מהחדש לישן (`created_at` יורד). בכל ריצה עברו על העמודים מ-offset 0 ועצרו ברשומה הראשונה שה-`created_at` שלה מוקדם מהריצה הקודמת. אין עדיין סינון `updated_since`, ולכן אי אפשר לשלוף רק רשומות שעודכנו: קראו מחדש את הרשומות שאתם עוקבים אחריהן עם `GET /{resource}/{id}`.
- **תור בצד שלכם** - אם האינטגרציה יוצרת הרבה רשומות בבת אחת (למשל ייבוא), שלחו אותן מתור בקצב של עד בקשה בשנייה.
- **מפתח לכל אינטגרציה** - כך עומס של מערכת אחת לא חוסם מערכת אחרת, וגם קל יותר לבטל מפתח בודד.
- **טיפול ב-429** - המתינו את מספר השניות שב-`Retry-After` ורק אז שלחו שוב.

```js
async function bantaFetch(url, init, attempt = 0) {
  const res = await fetch(url, init)
  if (res.status !== 429 || attempt >= 3) return res
  const seconds = Number(res.headers.get('Retry-After'))
  const waitMs = seconds > 0 ? seconds * 1000 + 250 : 2 ** attempt * 1000
  await new Promise((r) => setTimeout(r, waitMs))
  return bantaFetch(url, init, attempt + 1)
}
```

אם האינטגרציה שלכם צריכה קצב גבוה יותר באופן קבוע, פנו אלינו ב-[support@banta.co.il](mailto:support@banta.co.il).

---

חלק מתיעוד ה-API של banta. אינדקס מלא: https://docs.banta.co.il/he/llms.txt
