שגיאות, מגבלות וניסיונות חוזרים

כל API של Felo מחזיר גוף שגיאה ב-JSON עם קוד שגיאה יציב ומזהה בקשה. קראו קודם את סטטוס ה-HTTP, אחר כך את הקוד, ואז את ההודעה.

מעטפת השגיאה

תגובות הייצור הנוכחיות משתמשות בסטטוס ה-HTTP כ-status:

{
  "status": 401,
  "code": "UNAUTHORIZED",
  "message": "Invalid API Key",
  "request_id": "202610221444486982113280416060637185"
}

חלק מדוגמאות נקודות הקצה הוותיקות משתמשות ב-status: "error" ובמחרוזת קוד שונה. הסתעפו לפי סטטוס ה-HTTP ו-code, ולא לפי הנוסח המדויק של message.

קודים נפוצים

מסמכי נקודות הקצה מפרטים את הקודים הייחודיים לאותה נקודת קצה. התחילו עם שגיאות Chat API או עם המסמכים של נקודת הקצה שאליה אתם קוראים.

נקודות קצה ליצירת מודלים

POST /api/v1/images/generations ו-POST /api/v1/videos/generations מחזירים שגיאות ברמת נקודת הקצה במעטפת OpenAI במקום במעטפת שלמעלה:

{
  "error": {
    "message": "Model kind does not match this generation endpoint",
    "type": "invalid_request_error",
    "param": null,
    "code": "model_kind_mismatch"
  }
}

מזהה הבקשה נמצא בכותרת התגובה X-Request-Id, לא בגוף. בקשה שנדחתה אינה יוצרת משימה. ברגע שמשימה קיימת, רוב הכשלים מגיעים כסטטוס משימה סופי בתגובת 200 ולא כשגיאת HTTP: בדקו את status עבור failed או interrupted, ואז קראו את error.message. ראו יצירת תמונות ומשימות אסינכרוניות.

מזהי בקשה

גופי שגיאה של Felo כוללים request_id. תעדו אותו בלוג יחד עם נקודת הקצה, סטטוס ה-HTTP, קוד השגיאה, מזהה המודל ומזהה המשימה. לעולם אל תתעדו בלוג את מפתח ה-API המלא.

ה-Model API מקבל גם כותרת בקשה אופציונלית X-Request-Id. כשאתם שולחים אותה, היא מוחזרת אליכם לצורכי אבחון, מה שמאפשר להתאים את הלוגים שלכם לבקשה. אם אינכם שולחים אותה, השתמשו ב-request_id שמוחזר.

מגבלות קצב

/v2/chat היא נקודת הקצה היחידה של Felo עם מגבלות קצב מתועדות ונאכפות:

• לפי מפתח API, חלון של דקה.
• לפי משתמש, חלון של דקה.
• לפי משתמש, חלון של שעה.

משתמשים עם מינוי Felo בתשלום בתוקף, כולל מינויים ארגוניים, פטורים ואינם מקבלים כותרות X-RateLimit-*. אם לא ניתן לאמת את מצב המינוי, המגבלות עדיין חלות.

לנקודות קצה אחרות של /v2/** אין כעת מגבלות קצב נאכפות. בקשות Model API יכולות עדיין להיות מוגבלות על ידי הספק החיצוני, והדבר יכול להופיע כ-429.

אל תקבעו מגבלות מספריות בקוד. קראו את הכותרות בכל תגובה.

מדיניות ניסיונות חוזרים

לולאה מומלצת:

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

רצף איתור בעיות

1. בדקו שהמפתח קיים ולא בוטל.
2. קראו ל-GET /api/v1/models עם אותו מפתח כדי לאשר את האימות.
3. שלחו את הבקשה החוקית הקטנה ביותר לנקודת הקצה המיועדת.
4. הוסיפו סטרימינג, כלים או קלטים גדולים אחד בכל פעם.
5. בעבודה אסינכרונית, בדקו את מצב המשימה לפני שליחה מחדש.

קשור

• אימות
• ערוצים וניתוב ספקים
• משימות אסינכרוניות
• פתרון בעיות