خرابیاں، حدود اور دوبارہ کوشش

ہر Felo API ایک JSON ایرر باڈی واپس کرتا ہے جس میں مستحکم ایرر کوڈ اور ایک request ID شامل ہوتا ہے۔ پہلے HTTP اسٹیٹس پڑھیں، پھر کوڈ، پھر پیغام۔

ایرر انویلپ

موجودہ پروڈکشن جوابات HTTP اسٹیٹس کو status کے طور پر استعمال کرتے ہیں:

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

کچھ پرانی endpoint مثالیں status: "error" اور مختلف کوڈ سٹرنگ استعمال کرتی ہیں۔ فیصلہ HTTP اسٹیٹس اور code کی بنیاد پر کریں، message کے الفاظ کی بنیاد پر نہیں۔

عام کوڈز

Endpoint ریفرنسز اُس endpoint کے مخصوص کوڈز کی فہرست دیتے ہیں۔ Chat API کے ایررز یا جس endpoint کو آپ کال کر رہے ہیں اُس کے ریفرنس سے آغاز کریں۔

ماڈل جنریشن endpoints

POST /api/v1/images/generations اور POST /api/v1/videos/generations اوپر والے انویلپ کے بجائے OpenAI انویلپ میں endpoint سطح کے ایررز واپس کرتے ہیں:

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

request ID باڈی میں نہیں، X-Request-Id response ہیڈر میں ہوتا ہے۔ مسترد شدہ درخواست کوئی ٹاسک نہیں بناتی۔ ٹاسک بن جانے کے بعد زیادہ تر ناکامیاں HTTP ایرر کے بجائے 200 جواب میں آخری ٹاسک اسٹیٹس کے طور پر آتی ہیں: status میں failed یا interrupted چیک کریں، پھر error.message پڑھیں۔ تصویر جنریشن اور async ٹاسکس دیکھیں۔

request IDs

Felo ایرر باڈیز میں request_id شامل ہوتا ہے۔ اِسے endpoint، HTTP اسٹیٹس، ایرر کوڈ، ماڈل ID اور ٹاسک ID کے ساتھ لاگ کریں۔ مکمل API کلید کبھی لاگ نہ کریں۔

Model API ایک اختیاری X-Request-Id درخواست ہیڈر بھی قبول کرتا ہے۔ جب آپ ایک بھیجتے ہیں تو تشخیص کے لیے یہ واپس دہرایا جاتا ہے، جس سے آپ اپنے لاگز کو کسی درخواست سے منسلک کر سکتے ہیں۔ اگر آپ نہیں بھیجتے تو واپس شدہ request_id استعمال کریں۔

ریٹ کی حدود

/v2/chat واحد Felo endpoint ہے جس پر دستاویزی طور پر نافذ ریٹ کی حدود ہیں:

• فی API کلید، 1 منٹ کی ونڈو۔
• فی صارف، 1 منٹ کی ونڈو۔
• فی صارف، 1 گھنٹے کی ونڈو۔

جن صارفین کے پاس موثر بامعاوضہ Felo سبسکرپشن ہے، بشمول انٹرپرائز سبسکرپشنز، وہ مستثنیٰ ہیں اور اُنہیں کوئی X-RateLimit-* ہیڈر نہیں ملتا۔ اگر سبسکرپشن کی حالت کی تصدیق نہ ہو سکے تو حدود پھر بھی لاگو ہوتی ہیں۔

دیگر /v2/** endpoints پر فی الحال کوئی نافذ ریٹ کی حد نہیں۔ Model API درخواستیں پھر بھی اپ اسٹریم فراہم کنندہ کی طرف سے محدود ہو سکتی ہیں، جو 429 کی صورت میں ظاہر ہو سکتی ہیں۔

عددی حدود ہارڈ کوڈ نہ کریں۔ ہر جواب کے ہیڈرز پڑھیں۔

دوبارہ کوشش کی پالیسی

تجویز کردہ لوپ:

1. صرف idempotent یا دہرانے کے لیے محفوظ درخواستوں پر دوبارہ کوشش کریں۔
2. exponential backoff استعمال کریں: تقریباً 1 سیکنڈ سے شروع کریں، دوگنا کرتے جائیں، 30 سیکنڈ پر حد رکھیں۔
3. بے ترتیب jitter شامل کریں تاکہ کلائنٹس بیک وقت دوبارہ کوشش نہ کریں۔
4. چند کوششوں کے بعد رک جائیں اور ایرر سامنے رکھیں۔
5. 429 پر اپنے شیڈول کے بجائے Retry-After کی پاسداری کریں۔

ڈیبگنگ کی ترتیب

1. چیک کریں کہ کلید موجود ہے اور منسوخ نہیں ہوئی۔
2. تصدیق کی توثیق کے لیے اُسی کلید سے GET /api/v1/models کال کریں۔
3. ہدف endpoint کو سب سے چھوٹی درست درخواست بھیجیں۔
4. اسٹریمنگ، ٹولز یا بڑے اِن پٹس ایک وقت میں ایک شامل کریں۔
5. async کام کے لیے دوبارہ جمع کرانے سے پہلے ٹاسک کی حالت چیک کریں۔

متعلقہ

• تصدیق
• چینلز اور فراہم کنندہ روٹنگ
• async ٹاسکس
• مسائل کا حل