الغلاف
كل إخفاق، أيًا كانت الحالة، هو كائن JSON واحد:codeثابت وقابل للقراءة آليًا. تفرّع عليه لا علىmessage.messageشرح مقروء للبشر وقد يتغير.request_idهو UUID الطلب. يُعاد أيضًا في الترويسةX-Request-IDفي كل رد، نجاحًا كان أم فشلًا. اذكره عند الإبلاغ عن مشكلة.
error بنفس الحقول الثلاثة؛ راجع الرد المتدفق.
الرموز
يُفحص
agent_not_found وagent_disabled فقط في POST …/chat وPOST …/chat/stream. نقطتا نهاية GET لا تنظران إلى حالة الوكيل: مفتاح وكيل معطّل ما زال يستطيع عرض محادثاته وقراءة رسائله.
ما الذي يُعاد محاولته
أعد المحاولة بعد Retry-After بنفس Idempotency-Key
أعد المحاولة بعد Retry-After بنفس Idempotency-Key
idempotency_in_progress، conversation_busy، rate_limit_exceeded، api_rate_limit_unavailable، service_unavailable. إعادة استخدام المفتاح تضمن ألا تدفع مرتين للرسالة نفسها.أصلح الطلب أولًا
أصلح الطلب أولًا
validation_error (اقرأ message؛ فهي تسمّي الحقل المخالف)، idempotency_conflict (استخدم مفتاحًا جديدًا للجسم الجديد)، permission_denied (استخدم مفتاح full)، agent_mismatch (استخدم الوكيل الذي ينتمي إليه المفتاح).لا تعد المحاولة تلقائيًا
لا تعد المحاولة تلقائيًا
invalid_api_key (المفتاح حُذف أو السر خاطئ)، agent_disabled، agent_not_found، insufficient_balance (اشحن الرصيد أولًا). حلقة إعادة المحاولة على هذه الرموز لا تفعل سوى استنزاف حد المعدل.أبلغ مع معرّف الطلب
أبلغ مع معرّف الطلب
internal_error. أعد المحاولة مرة واحدة بنفس Idempotency-Key: السجل الفاشل يُحرَّر، فتشغّل إعادة المحاولة الطلب من جديد بدلًا من إعادة نتيجة مخزّنة. هذا متوقع، لكنه ليس مضمونًا أن يكون مجانيًا. إذا حدث الإخفاق بعد أن أجاب النموذج بالفعل، تنتج إعادة المحاولة ردًا جديدًا وخصمًا جديدًا. إذا استمر الإخفاق، أرسل إلينا request_id.ملاحظة حول 401
لا تفرّق API بين مفتاح محذوف ومفتاح لم يوجد قط: كلاهماinvalid_api_key. إذا بدأ مفتاح كان يعمل بإرجاع 401، تحقق من بطاقة الوصول عبر API في التطبيق؛ فالأرجح أنه دُوِّر أو حُذف.