تعرّف على أخطاء API الشائعة وأسبابها وكيفية حلها. استخدم هذا الدليل لتصحيح المشكلات وتطبيق معالجة أخطاء فعّالة في تطبيقاتك.
| Status | الاسم | الخطورة | وصف موجز |
|---|---|---|---|
| 200 | OK | Info | الطلب ناجح، الاستجابة جاهزة. |
| 401 | Unauthorized | Error | مفتاح API مفقود أو غير صالح أو منتهي الصلاحية. |
| 402 | Payment Required | Error | رصيد غير كافٍ لإتمام الطلب. |
| 403 | Forbidden | Warning | مصادق عليه لكن بدون صلاحيات كافية. |
| 404 | Not Found | Warning | النموذج المطلوب غير موجود أو مسار API خاطئ. |
| 422 | Unprocessable Entity | Warning | فشل التحقق — حقول مفقودة أو قيم غير صالحة. |
| 429 | Too Many Requests | Error | تجاوز حد معدل الطلبات، انتظر retry_after. |
| 500 | Internal Server Error | Critical | خطأ غير متوقع من جانب الخادم، أعد المحاولة. |
عند مواجهة خطأ، تُعيد واجهة LLM Resayil API استجابة JSON تصف ما حدث. فهم كيفية تحليل هذه الاستجابات ضروري لبناء تطبيقات قوية.
تتبع جميع استجابات الخطأ هذا التنسيق الموحد:
{
"error": {
"message": "Human-readable error message",
"code": 401
}
}
تحتوي بعض الأخطاء — كأخطاء التحقق (422) — على حقل إضافي errors
يوفر تفاصيل التحقق لكل حقل:
{
"error": {
"message": "Validation failed",
"code": 422
},
"errors": {
"model": ["The model field is required."],
"messages": ["The messages field must be an array."]
}
}
مفتاح API مفقود أو غير صالح في رأس Authorization.
HTTP/1.1 401 Unauthorized
{
"error": {
"message": "Unauthenticated.",
"code": 401
}
}
Authorization: Bearer YOUR_KEYاستُنفد رصيد حسابك. يجب إضافة رصيد للمتابعة.
HTTP/1.1 402 Payment Required
{
"error": {
"message": "Insufficient credits. Please top up your balance to continue.",
"code": 402
}
}
GET /api/billing/subscriptionتمت المصادقة لكن الحساب لا يملك الصلاحيات الكافية للوصول إلى المورد المطلوب.
HTTP/1.1 403 Forbidden
{
"error": {
"message": "You do not have permission to access this resource.",
"code": 403
}
}
النموذج المطلوب غير موجود، أو مسار API غير صحيح.
HTTP/1.1 404 Not Found
{
"error": {
"message": "Model not found.",
"code": 404
}
}
model بطلبكفشل التحقق من صحة الطلب. يتضمن الرد كائن errors يصف كل حقل به خطأ.
HTTP/1.1 422 Unprocessable Entity
{
"error": {
"message": "Validation failed",
"code": 422
},
"errors": {
"model": ["The model field is required."],
"messages": ["The messages field must be an array."]
}
}
errors لتحديد الحقول ذات المشكلاتmodel وmessagesmessages مصفوفة من الكائنات التي تحتوي على role وcontent
تجاوزت حد معدل الطلبات. تتضمن الاستجابة حقل retry_after
يحدد عدد الثواني اللازمة للانتظار.
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 20
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1741305600
{
"error": {
"message": "Rate limit exceeded",
"code": 429
},
"retry_after": 45
}
retry_after قبل إعادة المحاولةحدث خطأ غير متوقع من جانب الخادم. هذه الأخطاء نادرة وعادةً مؤقتة.
HTTP/1.1 500 Internal Server Error
{
"error": {
"message": "An unexpected error occurred. Please try again later.",
"code": 500
}
}
عند مواجهة أي خطأ، اعمل عبر هذه القائمة لتحديد المشكلة وحلها:
application/jsonX-RateLimit-Remaining في استجاباتكلا تكتفِ بالتحقق من رمز الحالة HTTP. حلّل JSON الخاص باستجابة الخطأ لفهم ما حدث وتقديم تغذية راجعة مفيدة للمستخدمين.
استخدم انتظاراً تدريجياً أسياً مع عشوائية للأخطاء القابلة للمحاولة (429، 500). راجع دليل حدود المعدل للتفاصيل.
سجّل استجابات الأخطاء كاملةً مع رموز الحالة ورموز الأخطاء ومعرّفات الطلبات. هذا يجعل التصحيح أسرع بكثير.
لا تعرض رسائل الخطأ الخام للمستخدمين. حوّل رموز الأخطاء إلى رسائل ودية وقدّم إرشادات عملية.
تابع X-RateLimit-Remaining في الاستجابات وقلّل الطلبات قبل الوصول إلى الحد.
اضبط مهلات الطلبات على 30 ثانية على الأقل للسماح للنماذج الأبطأ وزمن الشبكة.